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《本書の内容》 

•いまでは バソコン • ソフトといえども, 
大型機やワークステーションとかわらな 
いぐらい大規模な開発が行われています. 
•大きな ソフトウェアを効率よく，高品 
質につ<りあげるために考えられだのが 
「構造化設計」です. 

•永年 この分野の教育に携わつてきだ筆 
者が，構造化のコツをやさしく解説しま 
す. 
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はしがき 


ソフトウヱアの信頼性は，一般にハードウヱアの信頼性より低いといわれています•し 
かし，テストにかける費用は，ソフトウェアのほうがハードウェアより数段多い のが 普通 
です.つまり， ソフトウェアは手間をかけているにもかかわらず，製品と しての 信頼度は 
いまひとつといったところなのです. 

これはソフトウヱアの技術者が，ハードウヱアの技術者より腕が劣っていることを意味 
するのでしょうか.そうではないと思います.基本的な問題は，ソフトウヱアとハードウ 
ェアの複雑さのちがいにあります. 

ハードウェアは，形式と機能がきまっている機械命令を解釈し，忠実に実行すれば事が 
すみます.しかし，ソフトウヱアはそうはいきません.入力は適用業務ごとに異なります 
し，処理の仕方も業務ごとに異なります.また，機械命令はそれ自体個々に独立していて， 
他の命令間とのインターフヱースをとくに考える必要がないのに対し，ソフトウヱアで処 
理する問題には，機能間に複雑な関連があるのが普通であり.そのインターフ ヱ- ス 設計 
は大変やっかいです. 

このように，ソフトウヱアの信頼性の低さは，その複雑さに起因します.だからといっ 
て，信頼性の低さを容認してよいわけではありません.ゲーム.ソフトのエラーは，まだ 
笑ってすますことができるでしょうが，工場の生産ラインを制御するソフトウヱアの エラ 
一は，企業に大きな損害を与えるでしょうし，ばあいによっては，人命にかかわるような 
問題になることもあります. 

それだけに，信頼性の高いソフトウヱアを作成しなければならないという必要性は大き 
いのです.しかし，現実には，ソフトウヱア作成は，まだまだ個人に依存する部分が多く， 
信頼性の問題も，まだまだ個人の技術に依存しがちです.個人の技術への依存度を低めた 
高信頼性ソフトウヱアの設計手法の確立が望まれています. 

本書は，その1 つの 考え方である構造化(モジュール化)設計に ついて， 特に マイコンで 
プログラムを作成して いる 方を対象に，詳しく紹介して います. 

構造化設計の考え方は，もともと大型の コン ピュータで プログラムを 作成するときに 
有効な手法として注目されてきました.しかし，最近のように， マイコンと いえども大さ 
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な記憶容量をもつようになると，マイコンで処理するプログラムも，従来の大型コンピュ 
一夕で扱っていたのと同等の規模のものも出現するようになりました. 

したがって，構造化設計の必要性は，マイコンの分野まで広がってきています.エレク 
トロニクス技術の進歩は，今後，マイコンの処理能力をますます高めていくことになるで 
しょう.それとともに，プログラムの構造化設計の重要性も大きくなってきます. 

すでにふれたように，本書はマイコンでプログラム開発を行う方を対象に，できるだけ 
わかりやすくプログラムの構造化設計を説明することを目的としています.そのために， 
まず内容的にできるだけ具体性をもたせるよう努めました.文章を平易にすることはもち 
ろん，例題，図表をできるだけ数多く用いました.内容的には，設計部分は特定のプログ 
ラミング言語に依存するものでなく，すべての問題に汎用的に適応できるものです.ただ 
コーディング例は，マイコン技術者間で広く普及している C 言語， FORTRAN をベース 
にしました. 

本書は全部で9章から構成されています.第1章から第3章までは，プログラムの構造 
化設計を行うさいに身につけておかなければならない基本的事項について説明しています. 
まず，この部分をしっかり理解してください.第4章から第6章までは，構造化設計を具 
体的に展開していくときの手順，考慮点を中心に述べています.構造化設計の中心をなす 
部分ですので，説明にも大きなスペースをさいてあります. 

第7章は，分割した個々 のモジュールの 論理の設計について説明しています. コーディ 
ンダに直接つながっていく重要な部分であり，プログラムの読みやすさはこの設計のよし 
あしにかかっています. 

第8章では，コーディングしたモジュールをテストしながら，1つのプログラムにまと 
めていく方法について説明しています.最後の第9章では，構造化設計をより実際的に身 
につけるために，本格的な例題をもとに，設計からコーディングまでを一貫して説明して 
います. 

本書全体を通して読むことにより，プログラムを構造的に設計し，コーディングまでも 
つていく方法を具体的に理解していただけるはずです. 

最後に，本書の出版にご尽力くださいました CQ 出版社の山本潔さん，大野浩さんな 
ら びに ，㈱ エディックスの 中山洋一さんに心からお礼申しあげます. 

1991年12月 


著者 
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1• プ□ク'ラム開発の現状を理解しよう 


コンピュータがハードウヱアだけなら，何もできない単なる箱であり，そこに命をふき 
込むにはソフトウェアが必要であることは，いまならたいていの人は知っています.それ 
だけに，ソフトウェア，すなわち，プログラムの開発はコンピュータの出現と同時に行な 
われてきたわけですが，プログラムを作るという作業は，なにぶん，人手に頼る部分が多 
く，そこからいろいろな問題が発生しています. 

そこで，まず最初に，いままでのプログラム開発で何が大きな問題であったか，それを 
振返ってみることからはじめましょう.それらの問題を正しく認識し，その解決策を考え 
ることが，とりもなおさず，効果的なプログラム開発方法を考えることにもなるわけです. 

1.1 いままでのプログラム開発の問題点は何だろう 

同じ仕様のプログラムを10人のプログラマにあたえ，プログラムを作らせたら，10個 
の異なったプログラムができあがると言われることがよくあります.それくらいプログラ 
ムを作る仕事は属人性が強く，個人の技能に頼っているのが現状です. 

本書をお読みになっている読者の方々は，おそらく，いままでに何らかのプログラミン 
グの経験をお持ちの方が多いと思いますが，もしあなたがプログラム仕様書を渡され,プロ 
グラムを作ってほしいと頼まれたなら，まずどんな作業から手をつけていくのでしょうか. 

仕様書の内容を理解したら，早速コーディング用紙に向かい，最初の命令からコーディ 
ングにとりかかる方が，たぶん，たくさんいらっしゃると思います.あるいは，コーディ 
ング用紙ではなく，直接コンピュータ画面とにらめっこしながら，キーボードから手ぎわ 
よく命令を入力していく人も多いことでしょう. 

腕に自信のある方は，他の誰よりもよいプログラムを早く作成できる力を自分は持って 
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いるとひそかに思っておられるかも知れません（図 1.1). 

その自信に水をさすつもりはないのですが，自分の作ったプログラムに対して，下記の 
ような観点から，検討したとき，どれだけ自信をもって答えられるでしょうか. 

❿誰がみてもわかりやすいプログラムになっているだろうか 

•あとで仕様の変更が発生したとき，変更しやすいプログラムになっているだろうか 
•プログラム作成時に，エラーの修正にてまひまかけなかっただろうか 
參プログラムの設計という問題にどれだけ真剣に取組んだろうか.そもそも，プログラム 
の設計とは何だろうか.設計に対して明確な基準をもっていただろうか 
•できあがったプログラムの一部は，あとで他のプログラムを作成するとき，再利用でき 
るだろうか 

これらの問題にすべて自信をもってイエスと答え，しかも，その理由を明確に説明でき 
る方はプログラマとして大変優秀な方だと思います.しかし，現実には，イエスと答えら 
れる人よりも，首をかしげてしまう人の方がずっと多いでしょう. 

実は，これらの問題は，従来のプログラム開発の問題点として指摘されてきた重要なも 
のばかりなのです（図 1.2). 


図 1.1 よいプログラマとは 



3人とも自信満々.でも… 







1.1 いままでのプログラム開発の問題点は何だろう11 



他人より少しでも命令数の少ないプログラムを書き，実行時間を早くする.これこそが 
プログラマとしての腕の見せどころと考えておられる方がまだまだ多いのではないでしょ 
うか.確かに，この考え方は一理あるのですが，できあがったプログラムを先の5つの観 
点からみたときどうでしょうか. 

おそらく，命令数の少ない，実行の速いプログラムは，その論理が大変複雑になり，お 
世辞にもわかりやすいとは言えないはずです.開発時に，いろいろな試行錯誤が行われ， 
それだけ犯したエラーの数も増えてくる.また，変更しようとすれば，その変更の波及効 
果は大きぐプログラム全体を書き直さざるを得ない.もちろん，プログラムの一部を他 
に流用することなどとても不可能である.…まあ，こういったところに落ち着くのではな 
いかと思います. 

これらのことをいくつかの簡単な例でみていくことにしましょう. 
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1.1.1 問題点のあるプログラム例 

if(P>0) 
goto nq ； 
if(w>0) 
goto ns; 
t = 5; 
goto nr ； 
ns: s=4; 

goto nr ； 
nq: if(q>0) 

goto nx; 

Y=Z\ 
if(v<=0) 
goto nr ; 

r^n 

goto nr; 
nx: x=l; 

if(v<=0) 
goto nr; 

r^n 

nr ： r=6; 


► 特定の命令を実行するための条件さがし 

左の コーディング 例は， C 言語で書かれた 
プログラムの一部です が，ここで 
z = 3 

の命令を実施するのはどのような条件のとき 
かを考えてみてください. 

z = 3 の命令は2箇所にあらわれています 
ので，少し慎重に読み取っていく必要があり 
ます.まず， p の値が正かどうかを if 命令で 
テストしています. p が正であるときは， 
goto 命令で nq という名札のところへ飛んで 
いきます. 

一方， p が正でないときは，つぎのテスト， 
すなわち， w が正であるかどうかを調べま 
す.そして， w が正であれば，名札 ns へ飛 
びます. w が正でないときは， t =5 の命令 
を実行し，その後，名札 nr へ飛びます .w 
が正のとき，名札 ns へ飛んだ後は， s = 4の 
命令を実行し，その後，さらに nr へ飛んで 
いきます. 


さて，最初の条件テスト， p が正であるかどうかを調べて， p が正であったときは ， nq 
へ飛びました. nq では，つぎのテスト，すなわち， q が正であるかどうかを調べます .q 
が正であれば，名札 nx へ飛びます.正でないときは， y = 2の命令を実行後，さらに別 
のテスト， v が正でないかどうかを調べます. v が正でないときは，名札 nr へ飛びます. 
そして， v が正のときは z = 3の命令が実行されます.やっと目的の命令に到着できまし 
たね.ここまでの経路をブログラム上でたどると次のようになります. 
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goto nr ； 
nx ： x = l ； 


z 二 3 の命令がどのような条件のときに実 
行されるのか，いままでの追跡を整理するこ 
とで確かめてみてください.まず， v が正で 
あるときであることはいま確かめたばかりで 
すからすぐわかります.しかし， v のテスト 
を実施するのは，どのような条件のときかを 
調べる必要があります. 

それは， q が正でないときでしたね.また， 
q のテストはどのようなときにテストされた 
でしょうか.それは， p のテストで， p が正 
であったときでした. 

ここで，やっと答に到着できました.答は， 
• p が正である 
• q が正でない 
• v が正である 


if(v<=0) の三つの条件が満足されたときです. 

goto nr ； だいぶ，つかれましたね.しかし，残念な 

z =3; がら，これで問題が解決したわけではありま 

nr : r =6; せん. 

z=3 の命令は，このプログラムでは，もう 1 箇所，別の箇所で実行されています.す 
なわち，名札 nx の部分です.ここでの z = 3 の命令が実行される条件も調べる必要があ 
ります.せっかく，ここまできたのでですから，めんどうでももう少しがまんして調べて 
みてください.ここでは，答だけあげておきますので，皆さんの調べた結果と較べてみて 


正しいかどうかを確めてください. 


• p が正である 


參 q が正である 


參 v が正である 


先に出した答と比較してみてください.少しちがいますね.そうです. 「 n が正でな 
い」が，こんどは 「 q が正である」になっています（他の二つの条件は同じ）. 
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この二つの答を合わせて考えれば， q は正であってもなくても ， z = 3 は実行されるこ 
とになります.したがって， q の条件ははずしてかまわないことになります.そこで，求 
める答は 

• p が正である 
• v が正である 

の二つの条件が満足されたときとなります.このプログラムの論理をそのまま流れ図であ 
らわすと図 1.3 のようになります.この流れ図でみれば，コーディング例よりもかなりは 
っきりと z = 3 が実行される条件を追いかけることができますね. 


図 1.3 悪いコーディング例の流れ図 
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►このプログラムの特徴 

それにしても，だいぶ手間どりましたね.この コーディング 例の特徴はなんでしょうか. 
それは， goto 命令がたくさん使われていることです.それとともに，名札も多く使われ 
ています.このことが，このプログラムを必要以上にわかりにくくしていることは，すで 
に読者の方は気が付かれていることと思います. 


►プログラム例の改良 

このわかりにくいプログラムを，もっとわかりやすいものにするにはどうしたらよいの 
でしょうか.わかりにくさが goto 命令の乱発に起因しているのですから， goto 命令をで 
きるだけ使わないようにすれば，わかりやすくなるはずです. 

そこで，先ほどのプログラムの論理を変えないで， goto 命令を使わないプログラムを 
作ってみましょう.結果を下記に示します. 


if ( P >0) 

{ 

if ( q >0) 
x = l ; 
else 
y=2; 
if ( v >0) 
z = 3; 

} 

else 

{ 

if ( w >0) 
s = 4; 
else 


r = 6; 


t = 5; 
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この コーディング 例では ， z = 3 の命令は1箇所にしか出ていません.その分，考えや 
すいです ね.しかも， goto 命令が 一つ も使われていませんので，先ほどのように，あっ 
ちへ飛んだり，こっちへ飛んだりすることなくプログラムを追跡できます.さらに， if 命 
令の レベルに 応じて，命令の書き出し桁をずらして書いてあります（字下げのルールと呼 
ぶ) ので，その結果， if の制御範囲を大変明確に把握することができます. 

z =3 の命令は， p の条件テストが真のときで，かつ v の条件が真のとき実行されるこ 
とが，視覚的にも大変よくわかるはずです. 

同じ論理をコーディングしたにもかかわらず，先ほどの例よりずっとわかりやすくなっ 
ていることを理解できたと思います. 

このわかりやすいプログラムは，構造化プロダラミングという技法を用いることで作る 
ことができます.構造化プログラミングについては，コラム A に簡単にまとめましたが， 
詳細は後の章であらためて検討することにします. 

このように， プログラムを わかりやすく作成すれば，当然のことながら， エラーの 発生 
頻度は少なくなります.また，たとえ エラーを おかしたとしても，それをみつけ，修正す 
る時間は少なくてすむことになります. 

いままでの統計によれば，エラーの検出と修正に費す時間は，プログラム作成に費す全 
体時間の3割から5割を占めるといわれています.この時間が減少するということは，そ 
のままプロダラミングの生産性向上に大きく寄与することになります. 

►変更，追加のしやすさ 

また，プログラムをわかりやすく作っておけば，後で，そのプログラムに変更，追加の 
必要ができたとき，大変やりやすくなります. 

たとえば，このプログラム例で， 

• p >0 

• v <=0 

のとき， u =6 の命令を追加実行させるように変更したくなったとします. 


►わかりにくいコーディングへの追加 

最初にあげたわかりにくいコーディング例ではどうなるでしょうか.先程と同じように 
このコーディ ングの論理を追跡していき， u =6 の命令を追加する場所をさがさなくては 
なりません. その 詳細説明はくりかえしになる ので 省きますが，結構大変な作業でしたね. 
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コラム A 

ストラクチヤード • プログラミング 

構造化プログラミングとも呼ばれています.イタリアのコンピュータ技術者，ベームとヤ 
コピ ニが 最初に理論的に証明して注目されました.適正プログラム（入口が 一つで 出口 が一 
つのプログラム）であれば，その内容の如何にかかわらず，順次，選択，繰返し（図 A ) の3 
つの基本的制御構造の組合せによって，プログラムの論理を作成できるという構造化定理を 
用いてプログラミングするものです. 

その後，オランダのアイントホーヘン大学のダイクストラ教授によって世界的に紹介され， 
プロダラミングがアートから科学になったと評価されました. 

実用的にはそれまでの難解なプログラムをわかりやすいプログラムへ転換できる技法とし 
て注目され，現在多くのプロダラミングで採用されています. 

図 A 3つの基本的制御構造 



選択 
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結果は下記の示すように，矢印の処，2箇所に追加することになります.めんどうでも， 
自分でしっかり確めてみてください. 
if ( p >0) 
goto nq ； 
if ( w >0) 
goto ns ； 
t =5; 
goto nr ； 
ns ： s =4; 

goto nx ； 
nq : if ( q >0) 

goto nx ； 
y =2; 
if ( v <=0) 
u =6; | 一追加 

goto nr ; 
z = 3; 
goto nr ； 
nx : x = l ； 

if ( v <=0) 
u -6;1 一追加 
goto nr ； 
z =3; 
nr : r =6； 


►わかりやすいコーディングへの追加 

一方，わかりやすいコーディング例ではどうなるでしょか.こちらは goto 命令はあり 
ませんし， if の制限範囲も大変明確ですから，すぐ追加箇所はみつけられますね. p の条 
件が真のときの実行部分で， v のテストが偽の部分を追加すればよいのです.結果はつぎ 
のようになります.追加しても，わかりやすさは少しもそこなわれ ていない 点に注目して 
ください. 
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if ( P >0) 


if ( q >0) 
x = l ; 
else 

y=s ； 

I if(v>0)1 

z = 3; 
else 

u 二6;] ♦•追加 


else 

{ 

if ( w >0) 
s = 4; 
else 
t =5; 

} 

r =6; 

これまでにあげた例は，理解を容易にするために，ごく簡単な問題でした.したがって， 
わかりにくい例といっても，少し注意深く調べればミスをおかすことはまずないといって 
よいでしょう.わかりにくさ，わかりやすさは，あくまでも相対的なものであり，絶対的 
なものではありませんでした.しかし，問題そのものが複雑になってきたとき，この差は 
大変大きなものになります. 
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1.1.2 プログラムの機能設計(構造化設計)の例 

さて，いくつかの例でわかりにくいプログラムとわかりやすいブログラムについて考え 
てきましたが，このようなことを考えるのがプログラムの設計なのでしょうか. 

これまでの例は，プログラムの論理のよしあしが検討のテーマになっていました.論理 
のよしあしについて考えるのも立派にプログラムの設計のなかに入ります.しかし，それ 
がすべてではありません.論理の設計は，プログラム設計の一部なのです.そして，プロ 
グラムの設計を考えるときは，論理の設計の前に，ぜひ考えておかなければならないひと 
つのステップがあります.それはプログラムの機能設計(構造化設計)です.機能設計と論 
理設計のちがいの詳細は，後であらためて検討するとして，ここでは，具体例を中心に考 
えてみることにします. 

まず，プログラムの機能設計とは何かについて簡単にふれておきましょう.プログラム 
の機能設計では，最初にプログラムで解くべき問題をひとつの全体機能として把えます. 
たとえば，「3次元方程式を解く」，「大気汚染度を測定する」，「入院患者を監視す 
る」といったように.その全体機能をいくつかの部分機能に分割し，それらを階層構造的 
に合成(複合）していきます.そして，階層構造上の各機能を個々のモジュール(正確な定 
義は後述)に対応させます(図 1.4). 

簡単な例でみてみましょう.図 1.5 は，座席予約システムをごく簡単に類型化し，機能 
設計を行った例を示しています. 


図 1.4 機能設計の概略 
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図 1.5 座席予約システムの機能設計例1 



►機能分割 

この問題の全体機能は「座席を予約する」です.図 1.5 は，この全体機能を部分機能に 
分割し，それらを階層構造として合成した結果を示しています.「座席を予約する」機能 
は，「次のトランザクションを得る」，「空席を調べる」，「切符を発行する」の三つの 
部分機能から構成されます.さらに，これら三つの部分機能は，図 1.5 に示した，より小 
さな部分機能に分割されます.たとえば，「次のトランザクションを得る」は，「次の卜 
ランザクションを読み取る」と「トランザクションの妥当性を調べる」の二つの部分機能 
から構成されます. 

要は，階層構造の各レベルの機能は，より下位レベルの機能の総括とみることができま 
す.このようにみてくると，「座席を予約する」という全体機能を実施するためには，ど 
んな部分機能を実施しなければならないかが段階的に詳細化されていて，大変理解しやす 
くなつています.この理解のしやすさは，プログラムの仕様をつぎのように文章でだらだ 
らと一枚岩的に記述されたものと比較すれば，よくわかっていただけるはずです. 
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「この プログラムは座席の予約を行うためのものである.座席の予約を行うためには， 
まず要求トランザクションを読み取る必要がある.要求トランザクションは，別紙仕様に 
示すような一定の形式をもっていなければならない. 

正しいトランザクションであれば，そのトランザクションの要求していること，すなわ 
ち，何月何日の何便の予約をしたいかを知り，該当便に対するレコードをデータベースか 
ら読み取り，空席があるかどうかを調べる.空席があれば，切符を発行し，なければ，満 
席であることを端末操作員に知らせる.」 

おそらく，現実の予約システムの仕様はこれよりもっと複雑で細部にわたる説明が延々 
と続けられているはずです.それを全部読み取り，正確に理解し，プログラムのコーディ 
ングまでもっていくのは大変な作業になることでしょう.プログラムのコーディングを行 
う前に，仕様書で述べていることを図 1.5 のように整理するかしないかでは，そのコーデ 
ィングのやりやすさは随分とちがってくるはずです(図 1.6). 論理設計の前に機能設計が 
必要であると述べた理由は，まさに，この点にあります. 

図 1.5 のように機能分割したあと，個々の機能をモジュール対応させ，その後，モジュ 
ー ルの論理を設計していけばよいのです.その場合にも，わかりやすい論理が要求される 
のは，先の例でみてきたとおりです. 


図 1.6 機能階層図の効果 


るほど、 



文章表現はわかりにくい 


機能き構造化するとわかリやすい 
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1.1.3 プログラム設計の評価 

さて，図 1.5 に示したような機能設計の結果，プログラムで行うべきことが大変理解し 
やすい形で提示されたことは認めていただけると思います.しかし，この結果は，設計と 
して，はたしてベストなものなのでしょうか.機能設計の結果がよい設計になって いるの 
か，何か問題点があるのかをどのような観点から評価すればよいのでしょうか.われわれ 
は，いままで，設計結果に対する客観的な評価尺度をもっていたのでしょうか. 

このことの詳細については，おいおい明らかにしていきますが，設計の結果に対する評 
価は，いろいろな側面から把えていくことができます. 

図 1.5 の結果を例にとって，いくつかの側面から評価してみましょう. 

-►情報隠匿の概念 

先にも述べたように，この結果を機能的な展開図として評価すれば，なかなかよくでき 
ています.このプログラムで何を行うべきかが明確に提示されています.また，機能を階 
層的に展開するときに心掛けなければならない情報隠匿の概念も達成されています.情報 
隠匿の概念については，後の章であらためて述べますが，簡単にいえば，階層構造のそれ 
ぞれの レベルで，そのレベルでは 不必要 だと 思われる詳細情報はかくしてしまい， そのレ 
ベルでの 詳しさに設計の焦点を絞り，設計をやりやすくしようとすることです. 

たとえば，「座席の予約をする」ためには，どんな機能が必要になるかを考えるとき， 
必要な機能を大きなものから小さなものまですべて同時に把えて考える（図 1.7) のではな 
く，まず，機能を大まかに把えます.予約を要求している取引データ（トランザクション） 
を読み込み，そのトランザクションが要求している便の空席を調べ，空席があれば切符を 
発行するというのが座席予約の基本であることは誰でも理解できます. 

図 1.7 座席予約システムの機能設計例2 
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したがって，座席予約 システムの 機能階層図の上から2 番目のレベルを， 図 1.5 に示し 
たようにすれば，図 1.7 の例よりわかりやすくなるはずです.この段階では，トランザク 
ションを読み取るときに必要な細かな機能，あるいは，空席を調べるために必要な細かな 
機能は特に考えていません.それによって，座席予約のためには何が必要か，その大枠を 
しっかり把えることができるのです.これが情報隠匿の概念であり，設計時点での大切な 
考え方です(図 1.8). 

このような観点で，図 1.5 をもう一度見直していただければ，機能の詳細化が階層的に 
うまく行われていることがよくわかりますね.それがこの設計結果を図 1.7 よりわかりや 
すいものにしている主因です. 

ところで，プログラムの設計作業では，まず，機能設計が必要であり，その結果得られ 
た機能階層図の個々の機能をモジュールに対応させ，そのあと，個々のモジュールの論理 
を設計するのがよいことを先に簡単にふれました（図 1.4). 機能構造図は，モジュール構 
造図に変換され，そのあと，コンピュータで稼動できるようにコーディングされ，テスト 
されます.したがって，機能設計の結果は，コンピュータでプログラムとして稼動すると 
きに何か問題を発生しないかどうかの観点からもみていく必要があります. 

►影響範囲と制御範囲 

図 1.5 の結果をその面からみるとどうでしょうか.たとえば，この問題の性格から，一 
番中心になる機能は，おそらく， 「空席を調べる」のところになることでしょう.図 1.5 
では，空席を調べるために，まず，トランザクションが要求している便に対する レコード 
を データベースから 読み取ります.そして，その レコードを 調べて空席があるかどうかを 
チェックしています.空席があれば，切符を発行します.一方，空席がなければ，満席で 
あることを端末操作員に知 ら せ，処理す ベ きつぎのトランザクション を 読み取るようにし 
なければなりません. 

このことから，図 1.5 の機能構造図の「レコードを処理する」機能には，該当の便に空 
席があるか否かの決定が含まれることになります.そして，この決定結果によって，プロ 
グラムが次に行うべき機能が異なってきます. 

図 1.5 では，満席であれば，「レコードを処理する」機能の一部として「満席を知らせ 
る」機能を実行するようになっています.しかし，満席のばあいは，それだけではなく， 
つぎのトランザクションを得ることも必要です.図 1.5 では，これは，「レコードを処理 
する」機能の一部としてではなく，別の機能として把えられています.そして，この機能 
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図 1.8 情報隠匿の概念 



を実行させるための制御権は，階層構造図の最上位機能「座席の予約をする」がもってい 
ます. 

このことは，「レコードを処理する」機能のなかで行われた決定結果を「座席の予約を 
する」機能に教えてやる必要があることを示唆しています.そのためには，「レコードを 
処理する」と「座席の予約をする」の中間にある「空席を調べる」機能を介して，情報を 
知らせる必要があります（なぜ，そうなのかはモジュールの制御規約を理解する必要があ 
りますが，詳細は後の章で述べます). 

したがって，「レコードを処理する」のなかの決定問題は，「空席を調べる」と「座席 
の予約をする」機能に何らかの影響をあたえることになります.一つの決定問題がどこま 
で影響をあたえるかを，その決定問題の影響範囲と呼びます.図 1.5 の例では，決定問題 
を（◊)，影響範囲を （ x ) で示してあります. 

この決定問題は，空席があったことも意味しています.「切符を発行する」機能を実行 
する制御権は，その上位機能である「座席の予約をする」がもっています. 

以上から，つぎのことがいえます. 


春「レコードを処理する」機能のなかで行われた決定の結果は，「空席を調べる」機能を 
介して，「座席の予約をする j 機能に送られる. 

春「座席の予約をする」機能は，その決定結果を判断し，「次のトランザクションを得る」 
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図 1.9 決定問題 



機能か「切符を発行する」機能のどちらを実行するのかを決める必要がある（図 1.9). 

設計結果の評価として，ここで問題にすべきことは，決定がおよぼす影響範囲です.こ 
のばあい，影響範囲が大きくなればなるほど，その設計は好ましくないと言えます. 

何事でもそうですが，良い影響なら，その及ぼす範囲が大きければ大きいほど好ましい 
のですが，悪い影響は，なるべくならその及ぼす範囲は小さくしたいものです. 

ここで論じている影響範囲は，好ましくない影響ですから，できるだけ小さいほうがよ 
いのです.「座席を予約する」機能や「空席を調べる」機能からみれば，他の機能のなか 
で行われた決定によって，自分が何らかの影響をうけるのは，はた迷惑な話です.自分の 
ことだけ考えていればよいのではなく，他のことも気にしなければならないのですから 
(図 1.10). 

これは機能の独立性を低め，他の目的のために再使用する可能性をそれだけ低下させま 
す.また，変更があったとき，その波及範囲を広め， エラーの 発生確率を高めてしまうこ 
とになります.できれば，影響は自分が制御できる範囲内に留め他に影響を及ぼさないよ 
うにしたいものです.そして，そのような設計がよい設計なのです. 

プログラムの 機能構造図は， モジュール 構造図に変換され， プログラム として実行され 
ます.その意味では， モジュール のなかで行なわれる決定の影響範囲は，その モジュール 
の制御範囲のなかに留めるようにするべきです. 

モジュールの 制御範囲は， そのモジュール 自身と そのモジュールが 呼び出す モジュール 
(下位 モジュ ール）です（図1 .11). 

この観点から図1 . 5の結果を評価すれば，影響範囲が制御範囲をはみ出していて問題が 
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図1 . 10ほかへの影響はできるだけ少なく 



図 1.11 制御範囲は自分自身と下位モジュール 



あることがわかります.影響範囲を制御範囲内に収めるには，どうしたらよいでしょうか. 
この問題は，基本的には，設計者の創造力にゆだねられる分野です.まさに，設計者とし 
て知恵のだしどころです. 

この例題に対する設計の代替案を図1 . 12に示しておきましょう.図1 . 5の結果とよく較 
ベてみて下さい.どこがちがっていますか. 
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図 1.12 座席予約 システムの 代替え設計案 



そうですね.図 1.5 の階層構造の上位から2つ目のレベルでの3つの機能が，図1.12 
では，2つの機能にまとめられています.すなわち，「次のトランザクションの空席を調 
ベる」と「切符を発行する」の2つです. 

特に，「次のトランザクションの空席を調べる」機能にしたところが，この代替案のみ 
そです.機能をこのようにまとめることにより，この機能を実行するための部分機能(下 
位機能）として，「次のトランザクションを得る」，「データベースから該当レコードを 
読む」，「満席を知らせる」の3つを設定することができます. 

この案では，先に検討対象にした決定問題は，当然のことですが，「次のトランザクシ 
ョンの空席を調べる」機能のなかで行なわれすことになります.決定結果が，満席であれ 
ば，「満席を知らせる」機能と「次のトランザクションを得る」機能を実行します.決定 
結果が空席ありであれば，実行制御権を「座席を予約する」に戻します.このとき，「座 
席を予約する」機能は，決定結果を気にせず，「切符を発行する」機能を実行します•な 
ぜなら，制御権が戻ってくるのは，空席があるときに限られているからです.満席のばあ 
いは，「次のトランザクションの空席を調べる」機能の制御範囲だけで対応処理が可能で 
あり，制御範囲外に決定の影響をもたらすことはありません. 
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このことからみても，図1.12の設計結果が，図 1.5 の結果より好ましいと評価してよい 
でしよう.図 1.12 の結果は，先の情報隠匿の概念をも満たしています. 


►共通機能の分離 

それでは，図 1.12 の結果は設計としてべストのものなのでしょうか.問題の内容をつ 
ぶさに分析していけば，まだこの結果にも改良の余地があることに気がつきます. 

たとえば，「トランザクションの妥当性をチヱックする」機能があります.この機能の 
なかでひとつの決定問題が行なわれることでしょう.すなわち，トランザクションの形式 
を調べた結果，それが妥当であるか否かの決定です.このとき，妥当でなければ，トラン 
ザクション•エラーを何らかの形で知らせなければなりません.図 1.12 の設計では，この 
ことが「トランザクションの妥当性をチヱックする」機能のなかに包含されています. 

一方，「データベースから該当レコードを読み取る」機能にも注目してみましょう.こ 
こでは，トランザクションや要求した便に対する該当レコードの読取り作業が行なわれま 
す.しかし，このさい，何らかの理由で該当レコードがデータベース上にない可能性を考 
えておく必要があります.たとえば，トランザクションが形式的に妥当であっても，その 
内容の一部で指定した便が実在しないものである可能性があります. 

このようなときに，該当レコードなしのエラー•メッセージを打出す必要があります. 

そうです.いまとりあげた2つの機能，「トランザクションの妥当性をチヱックする」 

と「データベースから該当レコードを読取る」は，ともに，「エラー•メッセージを打出 
す」機能を包含しているのです.しかも，「エラー•メッセージを打出す」機能は，エラ 






30 第 1 章ブログラム關発の1状を理解しよう 


一•メ ッ セージの 内容は異なりますが，打出す機能自体は2 つの 機能間で共通であること 
でしょう. 

これは，この2つの機能をモジュールとしてコーディングするさいに，同じものを重複 
してもつことを意味しています.そのようなことになれば，作成の手間も重複することで 
大きくなりますし，プログラムもそれだけ大きくなり，無駄なコンピュータ資源を必要と 
します (図 1.13). それだけではなく，将来， エラー •メッセージ打出し機能に変更が生じ 
たとき，変更個所が複数になり，手間もかかるし，ばあいによっては， エラーの 原因にも 
なります. 

このような問題を避けるには，複数個所での共通機能は，それだけで独立させ，必要に 
応じて，その機能を呼び出すようにプログラムを設計すればよいのです. 

この観点から，図1.12の結果は，図 1.14 のように修正した方がよいことがわかります. 

図1.14座席予約システムの最終設計案 
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►まとめ 

このように，ひとつの設計問題でも，それをいろいろな側面から評価することにより， 

よりよい品質の設計に近づけていくことができます. 

重要なのは，設計評価の尺度をしっかりと設定することです.尺度がなければ，その設 
計結果がよいのか，よくないのか評価のしようがありません.評価したとしても，それは 
評価者の主観的な色彩が強くなり，客観的なものではありえないでしょう. 

いままでプログラム作成では，このあたりに大きな問題点があったのは先に指摘したと 
おりです.極論すれば，いままでのプログラム作成では，正しい意味でのプログラム設計 
は行われていなかったといっても過言ではありません.いままで述べたような，機能設計 
を行なわずに，プログラムの仕様書から直接コーディングを行なうのが常ではなかったか 
と思います.そこでは，プログラムの設計とは，論理の設計だけを意味していました. 

そのようにして作成されたプログラムは，モジュール化も不十分で，ひとつのプログラ 
ムのなかに，多くの機能がざつぜんとしてならべられ，時間がたてば，自分が作ったプロ 
グラムでも，何が何だかわからないような難解なものになりがちでした.そのようなプロ 
グラムは，当然，変更を困難にし，エラーの発生頻度が大きくなり，他の目的のために再 
利用する可能性などなきに等しいといった代物になってしまうことでしょう. 

こういったことになってしまう最大の原因は，くりかえすようですが，プログラムの設 
計に対する配慮が不足していることにあるのです. 

それでは，プログラムの設計とは何かについて整理してみましょう.この命題について 
考える場合，まず第1に，はっきりさせておかなければならないことがあります. 

それは，良いプログラムとは何だろうかということです(図1.15).なぜなら，プロダラ 
ムの設計は，良いプログラムを作るためのものだからです. 

良いプログラムとは，ひとことで言えば，わかりやすいプログラムのことです.いまま 
でのプログラムは難しく作る傾向がありました.それは，たくみな論理によって，命令数 
を少なくし，実行時間も速いプログラムが良いプログラムと考えられていたからです.こ 
のようなプログラムは，どうしても難しいプログラムになりがちです.難しいプログラム 
は，作るときにエラーをともなうことが多くなるし，その修正に多くの時間を必要としま 
す.変更に対処しにくいし，再利用の可能性も少なくなることは，すでに指摘したとおり 
です. 

したがって，良いプログラムは，わかりやすいプログラムということになるのです.そ 
して，プログラム設計の目的は，いかにわかりやすいプログラムを作るかにあります本 
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図 1.15 「よいプログラム」とは 



書の目的も，まさに，ここにあります.わかりやすいプログラムを作成するために，プロ 
グラムをどのように設計していくか.いままで，いくつかの具体例をとおして，機能設計 
(構造化設計）と論理設計の必要性を説いてきました. 

このことについて，こんどはもう少し体系的に説明することにしましよう.そのために 
は，まず，プログラムの開発手順を整理し，そのなかでのプログラム設計の位置づけと役 
割を正しく理解する必要があります. 
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1.2 プログラム開発の手順を整理してみよう 

プログラムは1つの 製品です. コンピュータでプログラムを 稼動させることにより，あ 
る種の問題の解決をはかります.パン焼き機はパンを焼くためにあります.洗たく機は衣 
服を洗たくするためにあります.それぞれ特定の機能をもっています. 

製品としてどんな機能をもつべきかは， その 製品の利用者の要求によって決まります. 
プログラム も他の製品と同様です. プログラムに どんな機能をもたせるべきかは， そのプ 
ログラムの利用者がプログラムに何を要求しているかによってきまります. 

したがって，プログラム開発は，そのプログラムに対する要件を定義することから始ま 
ります. 

製品に対する要件が定義できれば，次はその要件を満たすために，製品をどのように設 
計するかを考えなければなりません. パン 焼き器をどのように設計すれば他社製品よりも 
おいしい パンが 焼けるようになるのでし ょうか. 家庭の主婦が買いたくなる洗たく機はど 
のように設計すればよいのでしょうか.製品としての価値は，設計のやり方いかんできま 
ります. 

プログラムに関しても，この点はそのまま当てはまります.プログラムの製品としての 
価値は，その設計いかんによってきまります.利用者によろこんで使ってもらえるような 
ブログラムとなるように設計していかなければなりません（図 1.16). 


図 1.16 利用者のほしがるプログラムをつくる 



フ□グラムを必要とする客の行列 
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このように，1つの製品を開発していくためには，一定の手順が存在します.プログラ 
ムを1つの製品とみなしたとき，プログラムを開発するための一定の手順とはどんなもの 
なのでしょうか.そのなかで設計作業はどのような意味，重要性をもっているのでしょう 
か.まず，このあたりから整理していくことにします. 

プログラムの開発過程は，一連の変換過程とみることができます.すなわち，利用者の 
要求をコンピュータで稼動するプログラムに変換していく過程です. 

まず，利用者の要求を把握し，そのプログラムに対する要件として定義することが先決 
です. 

〔1〕要件定義 

すべてのプログラムは，それを利用する利用者がいるはずです.その利用者が，プログ 
ラムに何を望んでいるかを的確に把握することが，プログラム作成の第一歩です.病院の 
患者監視プログラムの利用者は，入院患者の異常をリアルタイムでキャッチし，それを看 
護婦に知らせる機能を望むでしょう.その場合，何をもって患者の異常とみなすのでしょ 
うか.血圧，脈拍，体温などいろいろな要因のうち，どれを監視の対象にすればよいので 
しょうか.これらの事を的確に把握し，プログラムに対する要件として定義していかなけ 
ればなりません. 

〔2〕外部設計 

要件定義ができれば，その要件をプログラムでどのような方法で実現するかを考えてい 
くことになります.これがいわゆる設計作業であり，設計作業は大きく 2つに分けること 
ができます.外部設計と内部設計です. 

外部設計は，利用者の立場からみたプログラムの設計です.換言すれば，利用者とプロ 
グラムとの間のインターフェースの設計です.わかりやすく言えば，利用者のために，そ 
のプログラムの使い方を設計することです.どんなデータを入力し，どんな出力がえられ 
るか，入力から出力への変換過程で，どんなデータ.ファイルが必要になるのかなどを設 
計することになります. 

先の患者監視プログラムの例では，入力として，一定時間ごとの患者の血圧値，体温， 
出力として，それらの異常値，測定したデータが異常であるかどうかを判定するための正 
常値ファイルの設計などを行うことになります.外部設計のやり方いかんで，プログラム 
の使い勝手のよしあしがきまります. 


. 
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〔3〕内部設計 

プログラムの使い方が設計できれば，つぎは，そのような使い方を可能にするために， 
プログラムの構造をどのように設計するかを考えます.すなわち，プログラムをどうモジ 
ュール化し，モジュール間のインターフヱースをどう設計するかが内部設計の主要作業に 
なります. 

この過程が，プログラムの構造化設計であり，いいかえれば，プログラムの構造化設計 
とは，プログラムが何をなすべきかの仕様が定義されたとき，プログラムの総体的な構造 
を設計するための手法です. 

構造化設計の入力となるのは，外部設計の結果であり，出力は，プログラムのモジュー 
ル構造と各モジュールの機能の定義，そしてモジュール間インターフヱースの3つという 
ことになります個 1.17). 

このように，内部設計はプログラムの内部構造を決定する作業であり，そのやり方ひと 
つで，プログラムのわかりやすさ，結果として，プログラムの品質がきまります. 


〔4〕プログラムの開発実施 

内部設計が終了すれば，つぎは プログラムの 開発実施です. ここでい う プログラムの 開 
発実施とは，構造化設計によって定義された各モジュールの論理の設計とコーディング， 

図1.17構造化設計の入力と出力 


ファイル仕様 
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複合設計 
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そしてテストです， 

これらの作業で重要なのは，構造化定理の活用です.構造化定理とは，世にいう構造化 
プログラミングの基礎理論をなすものであり，プログラム論理を順次，選択，繰返しの3 
つの基本制御構造の組合せで設計しようとするものです（コラム A ). このことについて 
は，第7章で詳しく検討することにします. 


〔5〕テスト 

プログラム 開発時点で，個々 に テストした各モジュールを， ひとつの プログラムとして 
統合し，プログラム全体として正しく稼動するかどうかをテストします. 

テスト手順としては，トップ•ダウン•テスト，ボトム•アップ•テストなどがありま 
す.このことについては，第8章で詳しく検討します. 

プログラム開発過程の要約を図1 • 18に示します. 


図 1.18 ソフトウヱアの作成過程 


工数 
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2. わかりやすいフ□クラム 


プログラム設計のねらいは，わかりやすいプログラムを作成することにあります.わか 
りやすいプログラムはエラーを減少させます.すなわち，信頼性の高い高品質のプログラ 
ムを実現させます. 

►複雑さを減少させる3つの手段 

それでは，どうすればわかりやすいプログラムになるのでしょうか.再び簡単な例で考 
えてみましよう. 


図 2.1 好ましくないプログラムの例 


main() 

long ppm [60], pol; 
int time, fcode, ecode; 
int 氺 ppol, *pecode; 

{ 

ppol = &pol ； 
pecode = decode; 


fcode = 0 ； 

table (fcode, time, 氺 ppol, 氺 pecode, ppm )； 
fcode = l; 

table (fcode, time, * ppol, 氺 pecode, ppm )； 


fcode = 2; 

table (fcode, time. 木 ppol, 氺 pecode, ppm); 
fcode = 3; 

table (fcode, time, * ppol, 氺 pecode, ppm); 
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図 2.1 に好ましくないプログラムの例を示します.この例では，好ましくない部分だけ 
を強調するために，他の部分は省略してあります.このプログラムでは， テーブル ppm 
に対する操作のすべてを関数 table によって行います. 

関数 table は5つのインターフェース•データ（引数）をもっています.最初の引数 
fcode は機能コードであり，その値が0のときは ppm のクリア，1のときは ppm へのデ 
一夕追加，2のときはデータの削除，3のときはデータの参照を指示しています. 

2番目と3番目の引数は， ppm に対する2種類のデータであり， time は時間， pol は 
その時間で測定した大気の汚染度であるとします. 

4番目のインターフェース • データは ecode です.この4番目のインターフェース•デ 
一夕 ecode は， エラー •コードであり，関数 table での処理に対して， エラーが 発生した 
とき， エラーの 種類によって 値が 設定されます. 5番目のインターフヱース•データは操 
作対象になっているテーブル ppm です. 

さて，このプログラムで何が好ましくないのでしょうか.一見するかぎり，テーブルの 
操作を一つの関数でまとめて行うように設計されており，設計者の苦労のあとが推察でき 
ます.しかし，関数 table の各引数について注意を向けると，混乱が生じます. 

fcode = 0のときの time, pol, ecode はどんな意味があるのでしょうが， ppm をクリ 
アするときは，じつは，これらの引数は，とくに意味をもちません.つまり，ダミーの引 
数なのです. 

fcode=l のときはどうでしょうか.このときは， ppm へデータを入力します.したが 
って， time, pol は入力引数になります.入力引数として指定した time，pol の値がテー 
ブル ppm へ追加されます. ecode は ppm のテーブル • オーバ フローが 発生したときに設 
定されるでしょう. 

fcode = 2は， ppm にあるデータのうち，指定されたものを削除します. 2番目の引数 
time で削除すべきデータを指定します. 3番目の引数 pol は，この場合特に意味をもち 
ません.すなわち，ダミー引数になります. ecode は， time で指定された削除データが 
テーブル ppm に見つからなかったとき設定されます. 

fcode = 3は， ppm の値を参照します.このとき，引数 time がキー入力になり，その 
時間の汚染度の値が出力として pol に戻されます. ecode は該当データが見つからなかっ 
たときに設定されることになります. 

このようにみてくると，関数 table を使用するときには，細心の注意が必要になること 
がわかります.使用目的によって，同じ引数がダミーになったり，入力になったり，出力 
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になったりします.また， ecode の値の意味もそのつど異なってきます.少なくとも，使 
用目的ごとに異なる引数の意味するところを，使用者は全部理解してからでないとうまく 
使いこなせないことになります. 

このように使用時に細心の注意を必要とすることは，それだけ エラーの 発生の確率を高 
め，信頼性をそこねることになります. 

しかし，このような例は，現実のプログラムで数多く使用されています. 

この例のようなプログラム設計は，設計者の労力にもかかわらず，事態を複雑にしてし 
まいます. 

わかりやすいプログラムを作るためには，この例がひきおこしたような複雑さを排除す 
るよう考えていけばよいのです.それでは，どうすれば複雑さを排除できるのでしょうか. 

プログラムに 限らず，どんな種類の システム でも共通に利用できる，複雑さを減少させ 
るための3つの手段があるといわれています.それは， 

籲分割すること 

籲独立性を高めること 

♦階層構造化すること 
の 3 つです. 

それでは，この3つの考え方について，もう少し詳しくみてみることにしましょう. 


2.1 小さく分割することを考えよう 


プログラムを複雑にする要素は何なのでしょう.第一の要素は，その大きさです.プロ 
グラムが大きくなればなるほど，そのプログラムを理解するために，人間が同時にたどり 
続けなければならない要素の数は増えます.要素の数が増せば，それだけ理解しにくくな 
ります.ある調査では，120個のプログラムの大きさの平均は853ステートメント（命令） 
であり，1個のプログラムで使用した変数の数は384個であったそうです.そして，それ 
らの変数が，そのプログラム内で平均1,195回出てきたとのことです. 

このことからみても，1個のプログラムの内容を理解することが容易では ない ことがわ 
かります.数百にもおよぶ変数の意味を正しく理解しながら，論理をたどることになりま 
す.まして，論理が入りくんだ複雑なものであったらどうでしょう. 

このような複雑さを減少させる手段は，プログラムを小さな単位，すなわち，モジュー 
ル （コラム B 参照）に分割することです.小さくすれば，同時にたどらなければならない要 
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素の数が減り，それだけわかりやすさが増します. 

プログラムをモジュール化すれば，必然的にモジュール間にインターフェースを発生さ 
せます.明確に定義されたインターフヱースは，プログラムをわかりやすくするのに役立 
ちます.なぜなら，インターフェースはどのデータがどこに関係するか，しないかを示し 
てくれるからです.それによって，注意の焦点をどこに絞ればよいかがわかります. 

ここで問題になるのは，その分割の仕方です.分割の方法をまちがえば，むしろ，あら 
たな原因で複雑さが増加することもあります.たとえば，1つのモジュールに多くの異な 
った機能を含めたり，逆に，共通の機能を多くのモジュールに分散させたりしたばあいで 
す.また，モジュール間のインターフェースが複雑で，複数のモジュールが期侍されない 
方法で相互に影響しあっているようなときも複雑さは増加してしまうでしょう. 

このようなことが生じないように，分割（モジュール化)時には考慮しておかなければな 
らない点があります.それが第二の独立性を高めるという手段になります. 


コラム B 

モジュールとサブルーチン 

プログラムの構造化設計を行うときの基本構成要素として，モジュールは大変重要な役割 
をになっています.似たような考え方として，サブルーチンという言葉があります.両者は 
どこが同じで，どこが違っているのでしようか. 

両者とも，プログラムの一部分を構成する要素であり，開始点と終了点がはっきりしてい 
てプログラムの他の部分と区分けされています.そして，必要に応じて他の部分から呼出し 
可能であり，そのために固有の名前がつけられています. 

ただ，サブルーチンは場合は，そのプログラム内だけで使用されるのに対し，モジュール 
は他のプログラムでも使用可能です.モジュールは別個の独立した1個のプログラムであり， 
単独でコンパイルされるものです.それに対しサブルーチンはそのプログラムの他の部分と 
必ず一緒にコンパイルされます. 
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2.2 独立性を高くしよう 

大きなものをいくつかの小さな単位に分け，個々の単位で考えていこうとするのが分割 
の概念でした.このとき，個々の分割した単位（モジュール）が，他のものから，できるだ 
け独立した存在になっていれば，他のことを考えずに自分の範囲内だけで物事の処理が可 
能になります. 

このことを1つの例で考えてみましょう.いま，手もとに1000ステートメントからな 
るプログラムがあったとします.さきほどの調査にもあるとおり，おそらく，このプログ 
ラムは数百個の変数をもっていることでしょう.そして，このプログラムを理解するため 
には，大変な労力を必要とするでしょう.そこで，分割の手段を用いていくつかのモジュ 
ールに分割することにします.理解を容易にするために，100ステートメントからなる1〇 
個のモジュールに分割することにします. 

分割の方法としてはいろいろ考えられます.1つの方法として，プログラムの1000個 
のステートメントの頭から順番に番号をふり，最初のステートメントを1番目のモジュー 
ルに，2番目のステートメントを2番目のモジュールに…といった具合に割り振り，11 
番目のステートメントになると，ふたたび1番目のモジュールに割り振っていくと，結果 
として100ステートメントからなる10個のモジュールに分割できます（図 2.2) 


図 2. 2よくないモジュール分割 

プログラム モジュール1 
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このような分割を行ったばあい，つぎのような結果が生じるはずです. 

•モジュール間の関連性が強くなり，ひじょうにはんざつになる.各モジュール内のステ 
一トメントは，自身のモジュール内のステートメントより，他のモジュール内のステート 
メントとと強い関連性をもつようになる. 

• もとのプログラムで行っていたいくつかの機能は，10個のモジュールに分散してしま 
う.見方をかえれば，各モジュールはいくつかの機能の一部分だけを実行することになる. 
作成したモジュールが，このような特性をもったばあい，つぎのような問題が発生しま 

す. 

•プログラムで 何をやろうとしているのか理解しにくい. プログラムで 実行するある機能 
を調べるためには，おそらく，分割した10個のモジュール全部を調べなければならない. 
•プログラムの 保守が むつ かしくなる. プログラムの ある機能に対して変更が必要になっ 
たとき，その変更は，すべてのモジュールに影響することになる. 

•新しいプログラムを作るとき，これらのモジュールの1つを再使用することができない. 
なぜなら，それぞれのモジュールで実行している機能を特定できないからである.モジュ 
—ルの再利用をはかる基本的な動機は，ある機能を生かすことである.機能を特定できな 
いモジュールの再利用を考える人はいない. 


図 2. 3独立性の概念 



独立性が弱ぃ赤ん坊 独立性が洩ぃ女性 
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►モジュールの結合度と強度 

これらの事実から，このような分割の方法がまちがっていることは明白です.そして， 
結果から，逆に分割はつぎのような方法で行うべきであることがわかります. 

«各モジュール間の関連性を最小にする. 

籲個々のモジュール内のステートメントの関連性を最大にする. 

この2つの事実こそ，独立性の概念です(図 2.3). 分割に際して，高い独立性を達成さ 
せるためには，関連性の低いステートメントは，別々のモジュールに分けるべきです.ま 
た，関連性の高いステートメントは同じモジュールに入れるようにすればよいのです. 

構造化設計では，前者の考え方をモジュール間結合度，前者をモジュール強度と呼び， 
結合度を最小にし，強度を最大にする方法を明示しています.強度，結合度については， 
この後第4章および第5章で詳しく解説することにします. 

2.3 階層構造化をはかろう 

複雑さを減少させる第三の手段は，階層構造化の概念です.階層構造化の概念は，プロ 
グラムを構築したり，理解したりするとき非常に重要です. 

先にも述べたように，プログラムを複雑にしている原因の1つは，同時に考えなければ 
ならない要因の数の多さにあります.ひとりの人間の頭で扱える要因の数は，ごく限られ 
たものであり，その範囲内で問題の解決をはかるためには，物事を小さい単位に分割して， 
個々の単位で独立して考えることを可能にすることと，もう1つは物事を階層構造的に定 
義していくことです.階層的なものの見方は，人間の注意の焦点をどこに合わせればよい 
かを指図することになり，理解を助けるのです.階層構造の各レベルは，より下位レベル 
要素間の関連性を集約したものです.このことは，そのレベルでは不必要に詳細な情報を 
かくして（情報隠匿の概念)，要約的にものごとを考えることを可能にすることを意味して 
います.人間は作成しなければならないプログラムの大きさが，大きくなればなるほど， 
それを一挙に作ることに困難さを感じます.考えなければならない多くの要因が同時に提 
示されるからです. 

その意味で，階層化して物事を考えるのは，概要から詳細へと段階的に整理することを 
可能にし，有効です（図 2.4). 

プログラムの 設計に さいして，モジュール 化をはかり，個々 のモジュールの 独立性を 高 
めたとしても，それらは，最終的には 一つのプログラムへ とまとめられなければなりませ 
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図 2. 5よい設計のための3つの手段 




図 2.4 階層構造の概念（それぞれのレベルでの役割がある） 




機能構造（モジュ-ル構造） 


機能間 インターフヱース 
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ん.そのことをふまえて，最初にモジュール化をはかるときに，個々のモジュールを階層 
的に分割するようにすればよいのです（図 2.5). それによって，モジュール化がやりやす 
くなり，かつ，プログラムの理解度が向上することになります. 

プログラムを モジュールの階層構造に分けるということは，換言すれば， プログラムの 
機能をト ップ ダウンで展開し，結果としてえられる機能階層構造をモジュール構造に対応 
させることなのです. 

このことは，独立性の概念とも密接な関係をもっています.詳しくは後の章であらため 
て考えることにします. 

ここでは，階層構造化ということを具体的イメージとして理解していただくために，簡 
単な例を紹介するにとどめておきましょう. 

図 2. 6は，大気汚染度の測定問題に対する最上位レベルの階層構造です.この問題の全 
体機能は，「大気汚染度を測定する」です.この全体機能は，次のレベルで，「測定値を 
入力する」，「測定値の平均値を計算する」，「平均値を出力する」の3つの機能に分割 
されています.これは，大気汚染度を測定するためには，この3つの機能を行なう必要が 
あることを示しています.また，逆の言い方をすれば，この3つの機能を集約したものが, 
全体機能として，大気汚染度を測定するになるということです.ここまで明らかになれば， 
必要に応じて，さらに，次のレベルへと詳細化していけばよいのです.たとえば，「測定 


図 2. 6階層構造の例 
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値を入力する」機能は，「1分ごとにデータを読取る」，「1時間分のデータにまとめ 
る」といった具合に…. 

このことから，概要から詳細へ，レベルごとに注意を集中することで，問題の理解を容 
易にし，わかりやすさを高めていくことが理解していただけるはずです. 

プログラムの 設計にさいして，これら3 つの 概念，分割，独立性，階層構造化を具体的 
にどのように実現していくかは，後の各章で順を追って説明します. 
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3. プログラム設計のだめの用語を定義し， 
表記法を身につけよろ 


わかりやすいプログラムを設計する第一歩は，分割することでした.要件と外部仕様を 
もとに，プログラムを一枚岩のように設計するのではなく， いくつかのモジュールに 分割 
して設計し，それらの モジュールが 最終的には，1 つの プログラムとして， ルールに そっ 
た稼動ができるようにすることです.すなわち，分解と合成の過程が必要になります. 

その意味で，分割は分解の過程であり，階層構造化は合成の過程ということもできます. 
このことをソフトウェアの設計過程で可能にするためには，モジュールというものを正 
確に定義し，その使い方に対するルールをしっかりと設けておく必要があります. 

3.1 モジュールを正しく定義し，その用法を理解しよう 

モジュールは，プログラムの基本単位です.実行可能なプログラム命令の集合であり， 
つぎのような規準に合致するものであるとします. 

⑴実行可能な複数のプログラム命令が語彙としてまとまっている.これらの命令群は， 
物理的に一緒になっていて，境界識別子（はじめと終わりを明確に示し，他との区別を 
可能にさせるもの）で区切られている. 

⑵これらの命令群は，固有の名前をもつことができ，他からその名前で呼び出すことが 
できる. 

(3) 単独にコンパイルできる（図 3.1( a )) 

このことから，モジュールは，プログラムを構造的にながめたときの基本単位とみるこ 
とができます.たとえば， Fortran 言語では，サブルーチン/サブプログラムがモジュー 
ルに該当します.図3 . 1 ( b ) はサブルーチン/サブプログラムの形式を示しています 
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図 3.1 モジュールの構造 



始めの境界識別子 


終りの境界識別子 


SUBROUTINE NAME (A, B) 

機能を処理する命令群 


RETURN 

END 


引数 

サブブログラム名（モジュール名） 


( b ) モジュールの例 


図 3.1( b ) で，最初に出てくる SUBROUTINE ステートメントがモジュールとしての始 
めの境界識別子になります.また，終りの境界識別子は END ステートメントであり，こ 
の間にある命令群がモジュールの中味になります. 

また， SUBROUTINE ステートメントに出てくる NAME はモジュール名となり，こ 
のモジュールを他から呼出すときに使われます. 

また，サブルーチン•サブプログラムは，他のモジュールとやりとりするデータを引数 
の形で指定することができます.引数としては，このモジュールに入力されるデータ，あ 
るいはこのモジュールから出力されるデータを必要な数だけ指定できます. 

C 言語では，モジュールに該当するのは関数です. 
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C 言語の関数は一般的に次のような形式をもっています. 
関数名(引数リスト) 

引数宣言 


} 

ここで，関数名はその関数固有の名前であり，プログラムでその関数が必要になったと 
きは，その名前により呼び出すことができます.これは先の⑵の条件を満たします.また， 
関数名（引数リスト） 

はその関数がそこから始まることも示しています.また， } はその関数の終りを明確に指 
示します.そして， {} の間にその関数が行うべきことを実行するための命令群が語彙 
としてまとまっています.それらの命令群は {} の間にすベて存在するわけですから物 
理的にも一緒の場所にあるとみなすことができます.これらのことから⑴の条件も満足す 
ることもわかるはずです. 

ただ，気をつけていただきたいのは，関数はその性格上，原則として出力は1つしか返 
せないことです.モジュールを一つの固有機能を実行する単位ととらえれば，その機能を 
実行した結果として，複数種類の出力を生み出すことは当然考えられます. 

FORTRAN のサブルーチン • サブプログラムでは，引数として複数の出力を指定でき 
ますので，ごく自然に処理できますが， C の関数ではこのあたりに工夫が必要になります. 

たとえば，出カ データの アドレス（ポインタ）を引数に指定すると いった 方法が考えられ 
ます. 

funcn ( inl , in £, pontl , pont 2) 
int ini , in £; 
int * poutl ,* pouts ； 

{ 

* poutl = 


* pout £ = 
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この例では， poutl ， pout 2 が出力を戻す引数であり，この関数を呼出す関数（たとえば， 
main 関数)で funcn ( inl , in 2，& outl , & out 2) と指定すれば, outl , out 2 に出力が戻され 
ます.なお，関数は特定のプログラム内だけて使用するのなら，そのプログラムと一緒に 
コンパイル することになるでしょうが，他のプログラムでも使用する場合は，別のソー 
ス •ファイル として単独に コンパイル すること も 可能です.その意味で，関数は モジ ュー 
ルの定義の⑶の条件をも満たしています. 

関数は引数リストを指定できることにも注目してください.わかりやすいプログラムを 
設計するための第1の条件，分割することの意義は，プログラムをなるべく小さい単位に 
分けて考えていけるようにすることと同時に，分けた単位（モジュール）間での イ ンターフ 
ェースを 明確にすることでした. インターフェースを 明確にすることで，どの データが ど 
こで使われたり，使われなかったりするのかがよくわかり，それが問題全体をわかりやす 
くすると説明しましたが，引数を指定するのは，まさに，このインターフェースを明確に 
することなのです(図 3.2). 

つぎに，モジュールを 使用するとき のいくつかの 約束をきめておきましょう.図 3. 3を 
よくみてください. この 図は モジュールの 使い方に対して基本的な事柄を示しています. 


図 3. 2インターフェースを明確に 
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図 3. 3モジュールの使い方に関する 


図3 . 4 モジュール実行時のルール 


基本的事項 


モジュール A 



•ここには，3つのモジュール A ， B ， C がある. 

♦モジュール A は，モジュールが C を呼び出す. 

籲モジュール B は，モジュール C を呼び出す. 

春モジュール B は， X という入力を受けとり，出力として Y をかえす. 

參モジュール C は， S または丁という入力を受けとり，出力としてそれぞれに S または 
Y をかえす. 

•モジュール B は，モジュール A に従属している. 

•モジュール C は，モジュール A と B の両方に従属している. 

これらの基本的事項から，モジュールが他のモジュールから固有の名前で呼び出すこと 
ができること，呼び出すときにモジュール間で入出カデータをパラメータとして引渡し可 
能なこと，モジュール間には従属関係（階層化)が存在することがおわかりいただけるはず 
です. 

また，これらの事実のほかに，モジュールの用法として，つぎの規準もきめておきます. 
あるモジュールが他のモジュールを呼び出したとき，呼び出した モジュールの 実行は， 
呼び出されたモジュ ーの 実行が終わるまで待たされる. 

呼び出されたモジュールの実行が終わると，実行は呼び出したモジュールに 戻る.そし 
て，呼出し命令のつぎの命令から実行する（図 3.4). 

以上のことから，モジュールの正確な概念と，それらが集まって，1本のプログラムと 
して稼動する仕組みがわかっていただけたと思います. 

ふたたび， C 言語の関数をとりあげてみますと，関数の用法はいま述べたモジュールに 
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図 3. 5モジュール間の制御の流れ 



関する用法をすべて満たしています.たとえば，図 3. 5ようなプログラムがあったとしま 
す 

このプログラムは，関数間の制御の流れを説明するのが目的ですので，目的外の詳細部 
分は省略してあります. 

さて，このプログラム例では， main 関数と moda 関数が存在します.このプログラム 
が実行するときは，まず main 関数の最初の部分から始まり ， x = 10 の命令を実行した後， 
制御は moda に移ります. moda では所定の論理を実行し，最後の return 命令を実行後， 
制御を main に戻します.図 3. 5はこのことを図示しており，これは図 3.3 のルールにそ 
っ た実行の形であることが理解できます. 

3.2 機能と論理のちがいを正しく理解しておこう 

いままでの説明で，モジュールとはどんなものなのかは正しく理解できたと思います. 
プログラムの構造化設計とは，1つのプログラムをいくつかのモジュールに分割し，それ 
を階層構造にまとめあげる過程です. 

その詳細に関しては，順を追って説明していきますが，その作業をはじめる前にぜひ知 
っておいてほしいのは，機能と論理の違いについてです.この違いを知ることは，プログ 
ラムの構造化設計を進めていくうえで大変重要なことなのです. 

構造化設計では，まずプログラムをモジュールに分割するときに，個々のモジュールの 
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機能を定義します.そのあと，モジュールの論理を設計します. 

ここでいうモジュールの 機能とは， そのモジュールがなすべきことです. 一方， モジ ュ 
ールの論理とは，モジュールがその機能をいかに実行するか，その手順を指します. 

機能と論理の違いをより正しく理解するために，いくつかの例で考えてみましょう.た 
とえば，旅行をすることを例にとってみます.話をより具体的にするために，夏休みに北 
海道へ10日間の旅行をするものとします.この場合，機能は「10日間の北海道旅行」で 
す.この北海道旅行を行う方法はいろいろあります.札幌まで飛行機で行き，その後，北 
海道内はレンタ•カーをかりて自動車でまわる.帰りは，また飛行機を利用する，あるい 
はすべての旅程に汽車を利用する，すべての旅程に自家用車を用いる，飛行機と汽車を利 
用する等々の方法が考えられます.ここであげたいくつかの例が北海道旅行をする機能の 
論理ということになります（図 3.6). 

このように，ある特定の機能を行うためには，いくつかの論理が存在します.もう1つ 
別の例をとりあげてみましょう.時計について考えてみます.時計の機能は，その時その 
時の正確な時間を示すことです.そして，この機能を行うためには，いろいろな方法があ 
ります.クオーツで知られているように，水晶発振器を用いる方法もあれば，いまはほと 
んどみられなくなりましたが，スプリングを用いたネジ巻き時計もありましたね.また， 
昔は，日時計，砂時計などもありました.これらは，時間を示すためのいくつかの方法で 
あり，論理なのです. 


図 3. 6機能と論理 
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プログラムの世界に話を戻しましょう.プログラムで行うべきことは，通常，プログラ 
ムの機能仕様書としてまとめます.そのプログラムで何を行おうとしているのか，それ 
がプログラムの機能なのです.そして，その機能を行うための手順を， C 言語や BASIC 
といったプログラミング言語でコーディングしていく，これがプログラムの論理の記述な 
のです.同じ機能を行うにも，作る人が異なれば，いろいろな論理のプログラムができる 
のは，読者のみなさんのほとんどは経験済のことでしょう. 

機能と論理の基本的なちがいは理解していただけたと思います.しかし，もう少し，機 
能と論理について続けて考えてみましょう. 

前章で，わかりやすいプログラムに設計するには，プログラムを分割すること，独立性 
を高くすること，階層構造化することの3つを守ることであることを説明しました.そし 
て，これらの3つの概念は，お互いに強い関連性をもっています.すなわち，独立性を高 
くして分割するためには，プログラムを機能的にみて分割する必要があり，機能的に分割 
していけば，結果として，機能が階層化され，それがプログラムのモジュール構造になっ 
ていくといったことです. 

このことから，これら3つの概念の関連性の基盤となっているのが，機能であることが 
わかります.そして，機能はより小さないくつかの機能に分割でき，それらが階層化され 
るということがわかります.1つの例でみてみましょう.図 3. 7は，病院の入院患者を監 
視するプログラムを機能階層化した例です.このプログラムの全体機能は，患者を監視す 
るです.そして，この機能を行うために，次の3つの機能を行う必要があります. 


図3 .7 「患者を監視する」の機能分割 
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_「患者の諸要因を得る」 

♦「危険要因をみつける」 

拳「危険要因を看護婦に知らせる」 

「患者を監視する」機能は，入院患者の体温とか血圧，脈拍などの要因を自動測定し， 
それらの要因の値に異常があれば，すぐにそれを看護婦に知らせることをさしています. 
そして，これらの三つの機能，たとえば，「危険要因を見つける」機能は，その患者の諸 
要因の正常値と測定値とを比較し，測定値が正常範囲外であれば，それが危険要因として 
認められることになります（図 3.8). 

この問題に対する詳細分析は，後の章で再度あらためて取りあげますが，図 3. 7〜図 3. 8 
の例から，機能を階層化するという意味が十分理解できるはずです.また，機能を階層的 
に分割することが，結果として，独立性を高くしていることにもなっています.このこと 
は，第4章で詳しくみてみることにします. 

ここでは，階層化したときの機能においては，あるレベルの機能は，その機能に従属す 
る（下位レベル)すべての機能を包含したものであることを十分くみとっておいて下さい. 
そして，このことは，機能をモジュールという用語におきかえても，そのままあてはまる 
ことなのです. 

すなわち，モジュールの機能は，そのモジュールに従属するすべてのモジュールの機能 
を包含します. 

ただ，ここで気を付けていただきたいのは， 

モジュール機能= 2従属モジュールの機能 

ではないということです.これは，上のモジュール機能についての文章的な説明と矛盾す 
るようですが，決してそうではないのです.これは図にすると明白になります.図 3. 9は， 


図3 .8 「危険要因をみつける」の機能分割 



図 3. 9 A = B + C + D +( A 自身の論理） 
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そのことを説明しています.この図で，機能 A は，従属する3つの機能 B ， C ， D を包含し 
ますが， B ， C ， D の3つの機能で A のすべてを表わしているわけではありません.機能 A 
は，機能 B ， C ， D で表わせる部分と，その他に自分自身の独自の論理部分をもっています. 
したがって，次のように言うのが，モジュール機能に対する正しい定義になります. 
「あるモジュールの機能とは，そのモジュール自身の論理とすべての直接従属するモジュ 
一機能とをまとめた一つの機能である」 

このことを C 言語プログラムを例にとってみればつぎのようになります. 
main () 

{ 

: ® 

b = funcb ( bl , b 2); 
c = funcc ( cl , c 2); 
d = funcd ( dl , d 2); 


この例で， main 関数（モジュール）は A 機能を表わしています.この main 関数は，自 
分自身の論理(点線部分®)と従属する3つの関数（モジュール) funcb , funcc , funcd から 
構成されています.この3つの従属関数がそれぞれの B ， C ， D を表わしています. 

これまでの説明で，いまや機能と論理という言葉がプログラム設計の分野で，どんな概 
念を表わしているのか十分ご理解いただけたはずです. 

ここで，この節の冒頭で述べたことをもう一度確認して下さい.プログラムの構造化設 
計とは，まず最初に，プログラムをモジュール分割することです.そして，モジュールの 
機能を定義します.つぎに，個々のモジュールの論理を設計していきます. 

モジュールの機能を定義するときは，それが論理的な表現にならないように気をつける 
必要があります.たとえば，主制御モジュールといった表現は使わないほうがよいのです. 
主制御という言語からうける印象としては，機能的なものより論理的なものを頭に描いて 
しまいがちだからです. 

機能的な表現をする簡単な方法は，機能の定義を一つの目的語と一つの動詞を用いて行 
ってみることです.「患者を監視する」，「危険要因を見つける」などの表現は，この形 
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で表わされていることにあらためて気^ r かれることでしょう. 

3.3 標準的な表記法をきめておこう 

プログラムの構造化設計を実際に進めていくときに，思考を明確にし，その結果を誰に 
でもわかりやすいものとして表現するための技法があれば大変役にたちます.そのための 
技法として，構造化チャートが一般的に使われます. 

構造化チャートは，機能あるいはモジュールを階層的に表現するための図的技法であり， 
プログラムを階層構造化した1組のモジュールとして表現すると同時にモジュール間のイ 
ンターフヱースの定義も行えるようになっています.手順(論理)は，原則として，表現せ 
ず，プログラムの静的な階層構造を表現するのがねらいです. 

構造化チャートの基本構成要素は，長方形の枠とその長方形を結びつける連係線です. 
長方形枠は一つのモジュールを表わします.枠の内部にモジュールの名前(機能）を書きま 
す. 


大気汚染度 

を測定する 

前もって作られた既存のモジュールを使用するときは，それが既存モジュールであるこ 
とを示すために，つぎのような縦線が2本の長方形枠を用います. 

平方根を計算する 

プログラムの内容によっては，複数箇所で同じ機能（モジュール）を実行することがあり 
ます.たとえば，複数箇所で エラー•チェックを 行い， エラーが あれば， エラー•メッセ 
ー ジを書出す場合などです. エラーの 内容は箇所によってちがいがあっても， エラー •メ 
ッ セージを書き出す仕事は，おそらく共通化できる でしょう. そのような場合は，共通モ 
ジュールとして，1つ作り，必要な箇所でそのモジュールを呼出し，使用します.共通モ 
ジュールであることは，長方形枠の右肩をぬりつぶすことによって表わします. 

エフ ー•メッセ 

ージを 書き出す 
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図3.10共通モジュールの使用 



図3.10は，共通 モジュールがモジュール 構造図で使わて いる 例です.正しい入カ データ 
が 得られなかったときと該当 レコードがデータベースに 見つからなかったとき， エラー. 
メ ッ セージが 書出されます. エラー •メ ッ セージの 内容は ちがっても メ ッ セージを 書出す 
方法は同じですので共通 モジュールが 使用されています. 

モジュール間に存在する連係線は，モジュールの呼出しを意味します.長方形の底辺か 
ら出ている線は，そのモジュールが他のモジュールを呼出すことを表わしています.逆に， 
長方形の上辺への連係線は，他のモジュールがそのモジュールを呼び出していることを表 
わしています. 



上の図で， モジュール A は， モジュール B と C を呼び出します.換言すれば， モジュ 
ール B ， C は， モジュール A に 呼び出されます. 
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ただ，この図では， A が B と C を何回呼び出すとか，どんなときに呼び出すとかまで 
は表現していないことに気を付けて下さい.それらは論理の問題であり，構造化チャート 
で表現するのは，原則として，機能の階層問係だけなのです. 

プログラムの構造化設計の表現でもう1つの重要なことは，モジュール間インターフエ 
ースの表現です. 

Z 



上の図で，連係線上の矢印と記号がインターフヱースを表現しています. X は A から 
B へ わたされるデータであり， Y は B から A へ わたされるデータを表わしています.ま 
た， Y は A から C へ， Z が C から A にわたされます.この関係を C 言語プログラムで 
表現すれば，つぎのようになるでしょう. 
main () 

{ 

int x , y , z ； 


y = iuncb ( x )； 
z = funcc ( y ); 

} 

funcb ( s ) 
int s , t ； 

{ 

return ( t ); 


fnncc ( u ) 
int u , v ; 

{ 

int v ; 

return ( v )； 

} 
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この例では，インターフェースとしての入出カパラメータの数が少なく，したがって， 
表現も簡単でみやすい形になっています.しかし，実際のプログラムでは，モジュール構 
造はもっと複雑になり，また，インターフヱース•データの数も増加します.そのような 
ときに，上記の表現法では，図が大変繁雑になり，みにくくなってしまいますので，イン 
ターフェース表現に関しては，つぎのような方法にするのがよいでしよう. 



入力 

出力 

1 

X 

Y 

2 

Y 

Z 

3 

S 

T 

4 

U 

T 



この方式では，モジュール構造図上では，インターフヱースは，直接データを記入せず， 
番号だけを記述します.そして，別のところに，インターフヱース表として，それぞれの 
番号のインターフヱースと入出カデータを記述します.この表において，入力，出力は呼 
び出されるモジュールの観点から定義されていることに注意して下さい（図3 .11)• たとえ 
ば，インターフェース1の入力 X は， A から B へ入力されるデータであり，出力 Y は， 

B から A へ出力されるデータを意味します. 

以上が，構造化チャートを用いて，プログラムの構造化設計を表現する場合の表記法で 
すが，これらの約束ごとに加えて，つぎのような規則を守るようにすれば，わかりやすさ 
がさらに増すことになります. 
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•プログラムの全体図は，なるべく1枚の用紙上に書く. 

どうしても，1枚に書ききれないときは，別のページとの連係を明確にしておく.たとえ 
ば，下のような接続子を用いる. 


ページ1 ページ2 

•同上用紙上での連係線の交差が多くなるときは，上のような接続子を用いてもよい•た 
だ，接続子の使用が多くなると，かえって，みにくくなることがあるので注意すること. 
•用紙上のモジュールの位置は，原則としては，プログラム構造上のそのモジュールの位 
置とは直接関係ない.しかし，できれば，用紙上で，上位モジュールの下にその従属モ 
ジュールがくるように書けば，その階層関係が理解しやすくなる. 

あるモジュールが複数個の従属モジュールを有する場合，従属モジュール間の横(階層 
構造上での同じレベル）の関係は，原則としては，何も意味しない.しかし，親モジュー 
ルがそれらの従属モジュールを呼び出す順序について，その段階で予測できるなら，その 
順序(左から右）にならベておくのがよい. 


① 

丄 

B 
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患者番号，危険要因 


体温，脈拍，血圧， 
皮虜抵抗，患者番号/ 



溫’抗脈 t 者血番 I ， 


3.4 表記法を用いていくつかの例を描いてみよつ 

それでは，構造化チャートを用いていくつか簡単な問題を描き，その良否について検討 
してみましょう. 

図 3. 12は，図 3. 7でとりあげた「患者を監視する」の機能構造図に機能間のインターフ 
ヱース.データを書き加えたものです.これは構造化チャートの標準的な表記法にそって 
書いたものです.長方形枠はモジュール(機能）を表わしています.枠のなかに機能名を記 
述しています.モジュール間の連係線でモジュールの従属関係を表わしています.すなわ 
ち，「患者を監視する」モジュールは，「患者の諸要因を得る」，「危険要因をみつけ 
る」，「危険要因を看護婦に知らせる」の3つのモジュールを呼び出します.この図では， 
基本的には，この3つのモジュールを呼び出す順序とか回数，条件といったものは表現し 
ていませんが，前節で述べたように，常識的には，左から右への順で呼び出すと考えてい 
いでしょう.機能的に考えても入力—処理—出力の順で左から右へならべることがわかり 
やすさにつながるはずです. 

ただ，この描き方で問題なのは，インター フヱース •データです. データの 数が多くな 
ると，どうしても繁雑になり，見にくくなりますね.やはり，このようなときは，図 3. 13 
のように，イン ターフェース 表のなかにイン ターフェース.データを まとめる方がみやす 
くなります.また，図 3. 14のように，階層構造を横展開で描く方法もあります.たて長 
の用紙上に描くときは，同ーレベルに多くのモジュールが存在するばあい，横展開の方が 
たて展開より書きやすい利点があります.しかし，モジュールや機能の従属関係を視覚的 

図 3. 12 「患者を監視する」の構造化チャート 
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03.13図 3. 12の修正 



にわかりやすくするのは，どちらかといえば，たて展開の方でしょうから，たて展開の方 
がよいか，よこ展開の方がよいのか，それは一長一短です. 

本書では，原則として，たて展開方式を採用していきます. 

図 3. 10には共通 モジュールの 描き方の例がでています. この 例では，共通 モジュール 
はそれを必要とする箇所で重複して描いています.用紙上の スペースに 余裕があるときは， 
このように描いた方が理解しやすいでしょう.ただ，この描き方は同じ モジュールを 複数 
個書くことになりますから，その分用紙の スペースを 費すことになり，限られた大きさの 
用紙に規模の大きな構造を描くときには向きません. 

そのようなときは，共通 モジュールは 1個だけ書き，それを必要とする モジュールから 


1113.14図 3. 12を横展開したもの 
(インターフェースは省略) 


図 3. 15共通モジュールのもう一つのかきかた 
(インターフェースは省略） 
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図 3. 16離れた位置の共通モジュールを呼ぶときは連経線を接続子で結ぶ 



連係線で結ぶ描き方がよいでしょう.例を図 3. 15に示します.この例では，隣接する2 
つの モジ ュ ー ルから共通 モジュー ルが呼び出されていて，連係線で結ぶときに大変都合が 
よくできています.実際には，このように都合がよいばあいばかりでなく，場所的に遠く 
はなれた複数個のモジュールが共通モジュールを呼び出すことがあります.そのばあいは’ 
図 3. 16に示すように，連係線を接続子で結ぶか，連係線同志を交差させる方法をとりま 
す. 

どの方式を採用するかの選択は，そのときの状況に応じて，どの方式が一番見やすいか 
を判断して決めることになります.もちろん，いくつかの方式を組合せてもかまいません. 
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4. モジュールの強度を強くすることを 
考えよ*5 


プログラムの設計過程において，分割の基本単位は モジュール であり， モジュールに 分 
割するときの重要な点は，独立性を強くすることでした. 

モジュールの独立性を高めるためには，前述したように各モジュール内の関連性を最大 
にすることと，モジュール間の関連性を最小にすることの2つの面から考えていく必要が 
あります. 

モジュール強度は，前者に関連したものであり，あるモジュール内の要素間の関連性に 
ついての1つの尺度です. 

プログラムのモジュール 化は，ずいぶん昔から行われていたことであり，とくに，新し 
い概念というわけではありません. 

ただ，モジュール化を行うときのはっきりした規準はなく，個人の考えにまかせていた 
傾向が強かったので，いろいろなやり方で行われてきたわけです.それらのやり方には， 
モジュール強度という観点からみて好ましいもの，好ましくないものが混在しています. 

表 4.1 は，いままでのモジュール化のタイプをモジュール強度の面からみて分類，整理 
したものです.ここには，7つのタイプがあらわれていますが，強度の低い順に上から下 
へとならべてあります.暗合的強度は一番低く，機能的強度は一番高くなります.強度が 
高ければ独立性も高くなるわけですから，結論からすれば機能的強度が望ましいわけです. 

ただ，何をもって強度が低いとか高いとかを判断するのかは，絶対的な基準が存在する 
わけではなく，各モジュールの相対的効果によって決めたものです.相対的効果とは，エ 
ラーの発生頻度，プログラムの保守のやりやすさ，モジュールの再使用性などの面から総 
合的に判断したものです. 

モジュール強度というものをよりよく理解するために，いくつかの強度を例にとって考 
えてみましょう. 
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表 4.1 モジュール強度一覧 


種類 

定 義 

特 徴 

暗合的 

• 機能を定義できない. 

• 互いに関係のない複数個の機能を実行 

•モジュール内の各要素間の関連性は低い.反対 
に，他のモジュール内の要素との関連性が高い. 
.インタ _ フヱースが複雑. 

•再便用，保守，拡張時に問題がある. 

論理的 

•関連したいくつかの機能をふくみ，そのうちの 
一つが呼出しモジュールによって選択され，実 
行される. 

. どの機能が選択されるかはインターフヱースで 
指示される. 

.単一のインタ ー フエ ー ス，パラメ ー タが機能ご 
とに解釈がちがったり，無視されたりする. 

. 一つの機能の使用に対しても，他機能の知識が 
必要. 

•インターフヱースの変更がすべての機能に影響 
する. 

• 機能コードとそのエラー•チェックが必要になる. 

時間的 

• 複数の逐次的機能を実行する.機能間の関連は 1 
時間的共通性以外にはほとんどない. 

•モジュール内の複数機能間の関連性は低い.反 
対に，他モジュール機能との関連性が高い. 

手順的 

• 複数の逐次的機能を実行する.機能問には問題 
仕様にもとづく関連性を有する. 

• とくに良い点もないが悪い点もない. 

連絡的 

• 手順的 +( 機能間にデータの関連性を有する）. 

• 手順的よりは強度は強い. 

情報的 

• 複数入口点をもつ. 

• 各入口点は単一の固有の機能を行う. 

. これらの機能はすべて共通のデータを扱う. 
.いくつかの関連した機能的強度モジュールを一 
つにまとめたもの. 

. データ構造の変更が一つのモジュールにしか影 
響•しない. 

• 論理的強度の問題点が解消できる. 

.独立性と拡張性が高く，エラー率が低い. 

機能的 

• 一つの固有の機能を実行する. 

• 強度は強い. 


4.1 強度が弱くなってしまうモジュール化は，どんな時に 
おきるのだろう力、 

〔1〕暗合的強度をもつモジュール 

暗合的強度は，強度が一番低いタイプですから，モジュール化にさいしては一番やって 
はいけないケースです.しかし，よくないものを最初に説明すれば，逆によいものがどん 
なものかがよく理解できると思いますので，最初にとりあげてみます. 

表 4.1 にその要約を示したように，「暗合的強度をもつモジュール」とは，つぎのよう 
な規準に合致するモジュールのことです（図4 .1). 

籲機能を定義することができない. 

籲複数のまったく関係のなレ、機能を実行している. 

すなわち-「このモジュールで何を実行しているのですか？」と聞かれても容易に説明 
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図 4.1 暗号的強度は中華料理店の丸 テーブル 



できないようなモジュールです.先にとりあげた1000個のステートメントからなるプロ 
グラムを10個のモジュールに分割するときに，ステートメントに順次番号を つけ それに 
従って割りふっていくというやり方は暗合的強度の典型的な例になるでしょう.このよう 
な型でのモジュール化は，何もしないよりもまだ悪い結果をまねくことになります. 

暗合的強度をもつモジュールは，プログラム内の活動範囲を個々のモジュール内にとど 
めるのではなく，むしろその反対のことを行っています.このタイプのモジュール内の各 
命令（ステートメント）は，関連性はあったとしてもそれは漠然としたものであり，逆に他 
のモジュール内の命令と密接に関連しあっているのです. 

もし，プログラムに変更が生じた場合，プログラムがいくつかの暗合的強度モジュール 
に分割されていれば，その変更はすべてのモジュールに影響を及ぼすことになるでしょう. 
1つの変更が多くのモジュールに影響すればするほど，エラーの入り込む可能性が大きく 
なり，プログラムの信頼性をそこねることになります. 

要するに，暗合的強度をもつモジュールは独立していません.他のモジュールとの関連 
性が強く，インターフェースも複雑になります.プログラムの保守性は低下し，再使用の 
可能性もほとんどありません. 

図 4. 2に暗合的強度を もつモジュールの 例を示しておきます. このモジュールで 何をや 
ろうとしている のか， 簡単に説明することはできません.無理に説明しようとすれば，お 
そらく， このモジュールの手順， すなわち，論理を説明することになってしまう でしょう. 
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図 4. 2暗号的強度の例 


coin (X ， y) 
int x, y. z ; 

{ 

z = x + y * 10 ; 

printf (“％5d %5d\n", x, y, z); 

if (z > 100) 
z = 100 ； 
return (z); 


たとえば， 「 y を 10 倍して，それに x を加えたものを z とし， z が100より大きくなれ 
ば， z を100にセットして，それをこの モジュールの 出力として戻す， X ， y ， z の元の値 
は印刷する」といった説明になるはずです. 

このようなモジュールを作る動機は，おそらく，このようなパターンがプログラム内に 
何度も出てくるとか，プログラムを何の考えもなしに，無造作にいくつかの部分に分断し 
てしまったとかの場合でしょう.結果として考えられるのは，このモジュールで実行しよ 
うとしていることは，何か大きな機能のごく一部であり，その機能の残りの部分は，他の 
モジュール（複数個あるかもしれない）で実行されるだろうということです. 

このような場合，その機能の変更は，このモジュールを含め，いくつかのモジュールの 
変更をうながすでしょう.また，このモジュールを他のプログラムが再利用する可能性は 
ほとんどないと考えてさしつかえありません. 

暗合的強度になってしまうようなモジュール化は，できるだけ避けるようにしなければ 
なりません. 

〔2〕論理的強度をもつモジュール 

暗合的強度をもつモジュールは，通常の神経の持ち主ならば，まず作らないはずです. 
したがって，実際にはほとんど見かけません. 

しかし，論理的強度をもつモジュールは，あちこちでよく見かけます.読者の皆さんの 
なかにも，この種のモジュールを作った経験をもっておられる方が多いものと思います. 
しかし強度の面からいえば，論理的強度をもつモジュールは，暗合的強度をもつモジュー 
ルについで良くないタイプに属します.「論理的強度をもつモジュール」とは，関連した 
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図 4. 3論理的強度は町の内科医院 



いくつかの 機能を含み，そのうちの 一つが 呼出し モジュール によって指定され，実行され 
る モジュールの ことです（図 4.3). 論理的強度を もつモジュールが 使用されるときは，必 
ず複数機能のうちどれを実行するのかの指示をパラメータで指定する必要があります. 
図 2.1 に示した好ましくないプログラム例は，じつはこの ケースに 該当します.ここで， 
もう一度このプログラムを見直してみましょう.見やすくするために，同じものを図 4. 4 
に再度示します.これは「大気の汚染度を測定する」プログラムなのですが，このプログ 
ラムでは，時間内の汚染度変化の様子を テーブルに 記憶します(表 4.2). 測定結果を貯え 
る テーブルに 対して いくつかの 機能が必要になります.たとえば， テーブルの 値をクリア 
するとか， テーブルに データを追加したり逆に削除したり，あるいは テーブルのデータを 
探索参照したりするようなことが，必要になるでしょう. 

このテーブルに関するいくつかの機能を1つのモジュール内にまとめ，実行させること 
は最近注目されているオブジヱクト指向プログラミングにそったものであり，実用上いく 
つかの利点があります.たとえば，テーブルの仕様を変更したとき，変更がそのモジ ュー 
ルに限定できることです.これはソフトウヱアの信頼性の面からは大変好ましいことです. 
一つの変更がいくつかのモジュールに波及すると，それだけ変更が大変になり，エラーに 
つながることは暗合的強度のところで考えました.したがって，現実にはこの種の論理的 
強度モジュールは変更の波及効果を小さくすることからよく作成されます. 
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図 4. 4好ましくないプログラム 


表 4. 2汚染度 テーブル 


main() 

long ppm[60J, pol; 
int time, fcode, ecode; 
int 木 ppol, 氺 pecode ； 

{ 

ppol = &pol ； 
pecode = &ecode; 

fcode = 0 ； 

table (fcode, time, 氺 ppol, 氺 pecode, ppm); 
fcode = l ； 

table (fcode, time, 氺 ppol,* pecode, ppm); 
fcode = S; 

table (fcode, time, 氺 ppol, 氺 pecode, ppm); 



ppm [0] 
ppm ⑴ 


ppm 〔 59 〕 


fcode = 3; 

table (fcode, time, 氺 ppol, ホ pecode, ppm )； 


►論理的強度の欠点 

しかし，モジュール強度的にみれば，先述したように，つぎのような大きな問題点を有 
しています. 

(1) 複数機能に対し単ーインターフ x — スをもつ. 

(2) 変更が高価になりがちである. 

(1) の問題は，インターフェースを必要以上にこみ入ったものにし，わかりにくいものに 
しています. 

表 4. 3は，大気汚染度テーブル操作モジュール table のインターフヱース仕様をまとめ 
たものです. 5種類のインターフヱース.データがモジュール（関数) table の引数として 
うけわたしされます.プログラム内では，引数 fcode ， time , pol ， ecode ， ppm がイン 
ターフェース•データにそれぞれ該当します.先にも述べたように，インターフェース* 
データは機能コード （ fcode ) によって指定された機能によって意味が異なってきます•テ 
ーブルのクリア機能に対しては，インターフェース.データ2, 3, 4は意味をもちません. 
すなわち，ダミーになります. 

また，インターフェース•データ3の汚染度 ( pol ) は，追加機能に対しては入力，探索機 
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表 4. 3 大気汚染度テーブル操作モジュールのインターフヱース 


インターフェース.データ 

1 

2 

3 

4 

5 

機能コード 

時間 

汚染度 

エラー. コード 

テーブル 

0 

クリア 

N • A 

N • A 

N • A 

入 Jj 

1 

追加 

入力 

入力 

出力 

出力 

2 

削除 

入力 

N • A 

出力 

入力 

3 

探索 

入力 

出力 

出力 

入力 


N.A : Not Available 


能に対しては出力というように変わってきます. エラー • コード （ ecode ) も出力であるこ 
とは変わりませんが，機能ごとにその値の意味するところは変ります.たとえば， エラ 
一.コードの 値が1のときは，追加機能では 「テーブル•オーバフロー」， 削除，探索 機 
能では「該当項目なし」といったことになるでしょう.これらの意味を間違えずに正しく 
理解することは，それほどなまやさしいことではありません. 

論理的強度モジュールを作る動機は，変更を局所化することにあることはすでに述べま 
したが，これも変更の内容によって話が異ってきます. （2) の問題は，このことを指摘して 
います.複数機能のうちのどれか一つの機能の変更が必要になったとしましょう.それが 
引数の数を増す必要があるような変更であれば，その変更と関係のない機能を使用してい 
るモジュールにも波及してしまいます.たとえば， fcode =2， すなわち，テーブルからデ 
一夕を削除する場合に，状況により，データをテーブルから完全に削除してしまうか，あ 
るいは，削除フラッグだけをつけるにとどめ，データはテーブル内に残しておくかのどち 
らかに分けたくなったとします.その場合，どちらにするかを指示するために，引数をあ 
らたに1個追加したとしましょう.いまや，モジュール table の引数は5個から6個にな 
ってしまいます.そして，これは，本来関係のない fcode = 0,1, 3の機能にも影響を及 
ぼします.なぜなら，モジュール table を呼出すときは，その機能の如何にかかわらず， 
引数を5個から6個に指定変えしなければならないからです.このモジュールを呼び出し 
ているプログラムが10個も20個もあるとすれば，考えるだけでいやになってしまいます 
ね. 

このほかに，論理的強度モジュールは，機能を指定するための機能コードを必ず持つが 
ゆえに，機能コードの値をチヱックし，それが正しいかどうかを調べる論理が必要になっ 
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てきます.そして，もし値がおかしければ エラー •メッセージを打出し，おかしいことを 
知らせる必要があります.たとえば，上の例では， fcode が〇〜3以外の値であればエラ 
一 •メッセージでエラーを 知らせる必要があります.これらの処理は，機能コードがある 
がために必要になるものであり，機能コードがなければ，必要のないものです.モジュー 
ルを単一機能を実行するように設計すれば，機能コードは当然のことながら不要になり， 
これらの処理も不要になります. 

このように，論理的強度をもつモジュールは良い点ももっていますが，大きな欠点もも 
っています.良い点を生かす方法は別にもありますので，なるべくならこの種のモジュー 
ルはさけたほうが賢明です. 

4.2 強度の強くなるモジュール化について考えてみよう 

〔1〕機能的強度をもつモジュール 

暗合的強度，論理的強度が強度的にあまり好ましくなかったのに対し，機能的強度は強 
度としては一番強く，モジュール化にさいしては，できるだけこの型にもっていくのが好 
ましいと言えます. 

「機能的強度をもつモジュール」とは，単一の機能を実行するモジュールです(図 4.5). 
図 4. 6は機能的強度をもつモジュールの例で，「配列を合計する」という単一機能を遂行 
するモジュールです.配列の合計を求めるために，モジュール内のすべての命令がお互い 


図4 . 5機能的強度は夫婦の絆 図4 . 6機能的強度の例 
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図 4. 7機能展開の例 



に関連しています.命令のどれ1つも欠かせません.このようなケースでは一部の命令だ 
けを変更する可能性は大変少なくなります.また，たとえ変更するにしても，その機能に 
対する変更であり，そのモジュールだけで処理でき，他のモジュールへの影響度合は小さ 
くなります.このような理由により，強度が強いと判定できるわけです. 

►単一機能とは何か 

ここで，注意する点は単一機能とは何かということです.それがはっきりしないと，モ 
ジュール化にさいして機能的強度を持たすことが難かしくなり，個人差が出てしまいます. 

機能とは，簡単にいえば入力を処理して出力に変換することです.数学的表現をするな 
ら，ッ=/(ズ)です.その意味では，ズをたんにッにおきかえるッも機能であり，2次 
方程式： y = 似 2 +加 +c も機能になります.とくに，2次方程式の場合は，それ自体1つ 
の機能でありながら，それをいくつかの部分機能に分解できることを示しています. 

たとえば，2次方程式を計算する過程ぬ: 2 ， y 2 = bx も 1つの機能とみなすことがで 
きます.なぜなら，0とズを入力にして:^という出力に変換しています.そして最後に 
少=义+ッ 2 + c を計算して目的を達成します.このことを整理すると図 4. 7のようになりま 
す.この図から，機能は階層的に展開できること，それを行うことで問題が理解しやすく 
なることがわかっていただける でしょう. じつは，このことはすでに図 3. 7〜図 3. 8で検 
討した「病院の入院患者を監視する」例でもみてきたことなのです. 

さて，それでは単一機能とは何を意味するのでしょうか.図 4. 7で示されて いるすべ て 
の機能は単一機能です. 2次方程式や患者の監視の例にみられるように，たいていの機能 
はいくつかのより低位の部分機能から構成されます.それらの複数機能をまとめて1つの 
機能ということができます. 
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2次方程式を計算する機能は，3っの単一機能「％ =似: 2 を計算する」，「於二如を計 
算する」，「ッニ义+災+じを計算する」からなりたっ単一機能です. 

また，「患者を監視する」は3っの単一機能「患者の諸要因を得る」，「危険要因をみ 
っける」，「危険要因を看護婦に知らせる」からなりたっ単一機能です. 

機能的強度をもっモジュールは単一機能を実行するモジュールです.「2次方程式を計 
算する」あるいは「患者を監視する」を1っのモジュールで実行させるときは，そのモジ 
ュールは機能的強度をもちます. 

►機能的強度をもたない例 

もう1っ別の例を考えてみましょう.ッ,=5ズ+3を計算する，ッ 2 = 3x 2 + 6x+9 を計算 
するという2っの単一機能があったとします.この2っの機能がとくに関連があるわけで 
ないとき，これらをまとめて一っの上位機能として表現できるでしょうか.むづかしいで 
すね.せいぜい「^=5^+3を計算し，っぎに:^ = 3x 2 +6x+9 を計算する」くらいにし 
か表現できません.これを1っのモジュールにまとめたとき，そのモジュールは機能的強 
度をもっとは考えません，ソフトウェアの仕様書のなかに，义を計算し，っぎにッ 2 を計算 
することを指示してあれば，これはこのあと説明する手順的強度になります.とくに指示 
がなければ，暗合的強度とみるほかないでしょう. 

分割したモジュールが，機能的強度になっているかどうかをごく簡単に判定する方法が 
あります.それは，そのモジュールで実行しようとしていることを説明するときに，1っ 
の目的語と1っの述語で表現できるかどうかを調べればよいのです.ですから，そのとき 
そのモジュールは機能的強度モジュールをもっとみなしてよいでしょう. 

〔2〕情報的強度をもっモジュール 

構造化設計では，モジュールを機能的強度にすることが望ましいのですが，その理由は 
変更が生じたとき，その影響範囲を局所化できること，再使用性が高まることなどでした. 
変更を1っのモジュール内に留まらせるという意味では，情報的強度も望ましい型という 
ことができます. 

「情報的強度をもっモジュール」とは，ある特定のデータ構造とかテーブルに対する複 
数の操作を1っのモジュール内に隔離したモジュールのことです（図 4.8). このことは情 
報隠匿の概念と呼ばれています.情報隠匿によってデータ構造とかテーブルに関する重要 
な変更を他のモジュールに波及させることなく行うことができます. 


4.2 強度の強くなるモジュール化について考えてみよう75 


図 4. 8情報的強度は担当部長 
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► 情報的強度とインターフエース設計 

先述の大気汚染問題の例で，テーブルに対する複数の操作を1つのモジュールにまとめ 
た論理的強度をもつモジュールを紹介しました. 

すでにおわかりの通り，論理的強度モジュールには，あまり好ましくないいくつかの特 
性がありましたが，情報隠匿の概念からいえば，うまいまとめ方をしているわけです. 

情報的強度は論理的強度と情報隠匿の概念では共通しています.しかし，決定的な違い 
があります.それはインターフヱースの設計です.論理的強度をもつモジュールでは，複 
数の機能に対して1つのインターフェースで操作します.情報的強度をもつモジュールは 
それぞれの機能に対して固有のインターフェースを設計します.すなわち，機能ごとにイ 
ンターフェースの持ち方をかえます.それによってダミーの引数や，機能が異なると同じ 
引数でも意味がちがってくるといったわずらわしさをなくすことができます. 

具体例でみてみましょう.図 4. 9は情報的強度モジュールの例です.この例は，図 4. 4 
の論理的強度モジュール table を情報的強度モジュールに変換したものです.論理的強度 
モジュール table は，テーブルに関する4つの機能，すなわち，クリア，追加，削除，探 
索を1つのモジュールで行おうとするものでした.それに対して，図 4. 9の例は，内容的 
には table モジュールと同じことを行おうとしています.ただ，入口点が4つあり，それ 
ぞれに対して異なる4つの名前がつけられています. TABLEC , TABLEA , 
TABLED , TABLES の4つです. 

これらの入口点は，クリア，追加，削除，探索の4つの機能に対応しています.また， 
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図4 . 9情報的強度の例 ( PL / I 言語) 


TABLEC : PROCEDURE : 

モジュ-ル全体のデータ宣言 

テーブル•クリア機能に固有のデータ宣言 

テーブル•クリア機能に対するコード 

RETURN ; 

TABLEA : ENTRY (TIME, POL) ; 

データ追加機能に固有のデータ宣言 
データ追加機能に対するコ-ド 

RETURN ; 

TABLED : ENTRY (TIME) ; 

データ削除機能に固有のデータ宣言 
データ削除機能に対するコード 

RETURN ; 

TABLES : ENTRY (TIME) ; 

デ-夕探索機能に固有のデータ宣言 
デ-夕探索機能に対するコード 

RETURN ; 


それぞれの機能を実行するときに必要になる引数データが，それぞれの入口点に指定され 
ています.機能ごとに引数が異なっている点に注目して下さい. 

図 4. 9のこのモジュールは，物理的には1つのまとまったモジュールです.しかし，い 
ま説明したように，それぞれの機能ごとに異なった入口点をもち，必要な機能ごとにその 
入口点から実行を開始します.たとえば，テーブルにデータを追加するときは，入口点 
TABLEA から実行を開始します.そして， RETURN 命令により呼び出しモジュールに 
戻ります. 

それぞれの機能に対する入口点と出口点は，他の機能のそれとは独立していますので， 
その意味では，情報的強度モジュールは，物理的には1つのモジュールでも，論理的には 
機能の数だけの独立したモジュールから構成されていると考えてよいでしょう. 

モジュールをこのように 設計しておけば，それを使用するときは，図4.10 の 形式にな 
ってくるでしょう.それぞれの機能に対応する異なる入口点名と引数が指示されているこ 


とに注意して下さい. 
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図4 .10 情報的強度モジュールの呼び出し 

static int pol_tab[2] [1440]， opol, ecode； 
main () 

{ 

int time, pol； 
tablec ； 

tablea (time, pol)； 
tabled (time); 
tables (time); 


このことから，モジュールを情報的強度に設計することで，情報隠匿の概念をいかしな 
がら論理的強度がもっていたいくつかの問題点が解消されることがわかります.すなわち， 
機能コードに対する引数が必要でなくなり，それにともなうわずらわしさが解消します. 
また，各機能ごとに固有の引数を指定できることにより，機能ごとに同じ引数の解釈が異 
なるといったこともなくなってしまいます.そして，機能固有の変更が，他の無関係な機 
能に影響を及ぼすといったこともなくなるでしょう. 

ただ，このような多重入口点をもつモジュールを作る場合は，プログラミング言語の制 
約をうけることになります.残念ながら，現在，製品として世に出ているプログラミング 
言語のなかで，多重入口点機能を使用できるのは，それほど多くありません.図 4. 9の例 
は， PL / I 言語を想定して作られていますが， PL / I が使用できるマイコンは，ほとんど 
ない のが 現状です. 

言語の制約から情報的強度 モジュールが 作れないときは，無理をせず，機能ごとに，単 
一機能を実行する別個の機能的強度 モジュールを 作るよう心がけましょう. 

0言語では，多重入口点機能はありませんが，機能ごとに別関数を作成し，それらをま 
とめて1 つのファイル として コンパイル すれば，結果として，多重入口点機能と 同等の こ 
とを行うことができます. 

C の上位言語である C + + では，情報的強度がねらいとしている情報隠匿の概念を具現 
化するためにはクラスを用いることもできます.たとえば，次のようにクラスを定義しま 
す. 



78 第 4 章モジュールの強度を強〈することを考えよう 


class tableop 

{ 

long ppm [60]; 
public : 

void tablec ( long *)； 
void tablea ( int , long , long *); 
void tabled ( int , long *); 
void tables ( int , long 本， 101 lg 本)； 

}； 

この定義では，情報隠匿の対象になっているオブジヱクト， ppm テーブルはクラス内の 
メンバ関数だけが操作でき，プログラムの他の部分からは操作できないようにしています. 
しかし，ここで定義された4つのメンバ関数 tablec ， tablea ， tabled , tables はプログラ 
ムのどの部分でも使用できます. 

C + + では，クラスは利用者が目的に応じて定義する1つのタイプ ( long とか int と同 
じ）ですから，クラスを使用するときは 
tableop ppmtbl ; 

のように宣言する必要があります.そして，クラス内のメンバ関数をプログラムのどこか 
で使用するときは 


ppmtbl . tat ) lec ( ppin ); 

ppmtbl.tablea(time, pol, ppm); 


ppmtbl . tabled ( time , ppm ); 


のように使用します. 

このような形でクラスを定義しておけば，オブジヱク ト である テーブル ppm はクラス 
内だけで処理できることになり，もし テーブルに 変更が生じてもクラス内だけで処理する 
ことができ，変更の波及効果を局所^:できることになります. 

なお，メンバ関数を定義する（クラス内では宣言しているだけ）には，次のように行いま 


す. 
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void tableop :: tablec ( long * ppm ) 


ここで， tableop はクラス名であり， tablec はメンバ関数名です.クラス名とメンバ関数 
名の間にバを必ず入れるようにします. 

このように，オブジェクト単位にクラスを定義し，ブログラムで使用していくのがオブ 
ジェクト指向プログラミングであり，情報的強度モジュールはまさにこの方向にそったも 
のであるということができます. 

4.3 その他の強度をもつモジュールについて考えてみよう 

いままでに説明した強度の他に，まだいくつかの強度が考えられます.それは，時間的 
強度，手順的強度，連絡的強度といったものです.これらの強度は，強度的には中間に属 
しますが，利点より欠点の方が目につきます. 

その意味では，構造化設計を行うさいには，特に強い理由がない限り，これらの強度に 
なるように設計するのはなるべく避けた方が無難です. 

以下，3つの強度について簡単な例を通してみてみましょう. 

図 4. 11は A，B 2つのタイプのトランザクションを読み取り，それを処理するプログラ 
ムの処理手順の大枠を示したものです. 

この図をもとに，このプログラムをいくつかのモジュールに分割します.いま，図 4. 11 
の太線で囲んだ4つのモジュールに分割したものとします. 

モジュール INIT は初期設定を行います.ファイルのオープンであるとか，合計域，テ 
ーブルのクリア作業などがこのモジュールの役目になります.これらの作業を最初にまと 
めてやってしまうことは，プログラムならだれでも考えることだと思います. 

モジュール MAINPROC は，全トランザクションを处理します.もちろん，このプロ 
グラマの中心になる部分です.この MAINPROC は，トランザクションのタイプを調べ， 
タイプごとに異なった処理を行う部分を RECPROC という子モジュールとして分割し， 
必要に応じて呼び出すようにしています. 4つ目のモジュール TERM は終了処理モジュ 
ールです.最終合計の出力などがその作業内容になるでしょう. 

この4つのモジュール構造を構造化チャートで表現すると図 4. 12のようになります 
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図 4. 112種類のトランザクションを処理するプログラムの大枠手順 



図 4. 12図 4. 11のプログラム•モジュール構造 
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さて，このように分割した4つのモジュールを強度的にみてみましょう. 


〔1〕時間的強度をもつモジュール 

モジュール INIT について考えてみます.このモジュールの特徴は，“プログラム実行 
開始の段階で行っておかなければならないことをすべてまとめて行って いる” ことです. 
その意味では，このモジュール内の命令は時間的に強い関連をもっています.このような 
モジュールを「時間的強度をもつモジュール」とよびます. 

この観点からみれば，モジュール TERM も時間的強度をもつことが容易に理解できる 
はずです.時間的強度をもつモジュールは，特定の時点で行うべきことをすべてまとめて 
行うため，プログラマにとっては考えやすい面があることは事実であり，現実にもよくこ 
の型のモジュールが作成されます. 

しかし，時間的強度モジュールは大きな問題点をもっといます.それは，このモジ ュー 
ル内の命令が機能的にみれば，互いにあまり強い関連をもっていないことです.逆に，ほ 
かのモジュール内にある命令と強い関連をもつ可能性があります.カウンタのリセット， 
テーブルのクリアなどは互いに機能的に関連があるわけではなく，たまたまプログラムの 
実行開始時点で行うという共通点をもつがゆえに1つのモジュール内に入っているにすぎ 
ません.むしろ，カウンタはカウンタを処理するほかのモジュール内の命令と強い関連を 
もちますし，テーブルもテーブルを処理するほかのモジュール内の命令と強い関連をもち 
ます. 

このことは，カウンタやテーブルについて考えるとき， INIT だけでなく，ほかのモジ 
ュールのことも考えなくてはならないことを示唆しています.もし，カウンタのけた数や 
テーブルの大きさの変更が必要になったとき，関連するモジュールすべてに影響します 
(図4.13). 

この意味で，時間的強度は独立性が高いとはいえず，分割の形としてはあまり好ましく 
ありません. 


〔2〕手順的強度をもつモジュール 

次に，モジュール MAINPROC と RECPROC について考えてみます . MAINPROC 
は，図 4. 11の問題解決の大枠の手順を表現した流れ図の一部分をまとめてモジュールに 
したものです.また， RECPROC は MIANPROC に含まれた手順の一部をまとめてモジ 

ュールに したものです. 


モジュールの強度を強くすることを考えよう 

図 4. 13時間的強度モジュール 

〈ほかのモジュール〉 



〈ほかのモジュール〉 
(テーブル操作） 


• 時間的強度モジュールの命令は 
自モジュールの命令との関連性は 
弱く，他モジュールの命令との関 
連性が強くなる傾向がある. 


このことは， MAINPROC と RECPROC は親子関係 ( RECPROC が MAINPROC に従 
属している）であることを表しています.図 4. 12のモジュール構造はこのことを示してい 
ます. 

MAINPROC , RECPROC のように，問題解決のための手順をもとに，その手順の一 
部をモジュールとしてまとめたものを「手順的強度をもつモジュール」とよびます. 

手順的強度の特徴についてみてみましょう.手順的強度をもつモジュールは，問題解決 
のための手順に基づいてモジュール化したものですから，モジュール内の命令も当然問題 
解決手順的に関連しており，それなりに関連性の強さをもっています.少なくとも，先述 
の時間的強度よりは強度が強いとみなせます. 

しかし，手順的であるということは，機能的であることとは本質的に違います.1つの 
モジュール内に収められた手順は，機能的にみれば，単一機能のうちの一部だけを実行す 
るかもしれません.あるいは，逆に複数の機能を含んでいるかもしれません. 

RECPROC をみても，そのなかにはトランザクション A と B の処理， エラー 処理など 
を含んでいます.これらはそれぞれ1つの機能とみなすことができるので ， RECPROC 
は複数個の機能を含んでいるとみなせます. 

これは RECPROC を作成するとき， A ， B 両方の処理とエラー処理を考える必要がある 
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ということであり，同時に考慮しなければならない要素の数がそれだけ多くなることを意 
味しています.また， A に対する変更が生じたとき， A の処理とそれ以外の処理とを見 
分けながら手当てしていかなければならず.修正作業を困難にします. 

前節でみたように，最適な モジュール 化は単一機能を1 つのモジュールに まとめること 
であり，本質的に手順的強度 モジュールは こ の 原則と一致しません. 

機能と手順は，本質的には違うものであることを認識しておく必要があります.機能は 
何 ( what ) を行うかを表すものであり，手順は機能を実行する方法 ( how ) を示します.先 
に機能と論理を区別した理由は，まさにそこにあります. 

プログラム設計では，まず，その ブロ グラムで行うべきことを明らかにし，次にそれを 
行うための手順を考えていきます.その大きな理由は，機能と手順を明確に区別せず，最 
初から手順指向で設計すると，そのプログラムで何を行うべきかという最も大切な点がぼ 
けてしまうからです. 

モジュール 化は， プログラムの 機能を明確にするねらいを もっています.その 意味で， 
手順的強度は モジ ュール化の本質的な意図に そ ぐわない のです. 

モジュールが手順的強度になってしまうのは，流れ図のような手順を示すものをもとに 
モジュール化することに起因します.流れ図は機能的にモジュール化することに対して何 
も伝えてくれないことを知っておく必要があります. 

時間的強度と手順的強度は，モジュールの独立性の面からみれば，あまり望ましい形で 
ないことは理解していただけたと思います. 

それでは，時間的強度，手順的強度がもっている問題点を解消し，よりよい機能的なモ 
ジュール 化を図る にはどう したらよいで しょうか. 

図 4. 14図 4. 11の問 r ょ一-"-…、 1 - 
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図 4. 15 DFD をもとに作成したモジュール構造 



► DFD (Data Flow Diagram ) 

1つの方法は，モジュール化を考えるさいに，手順指向の流れ図でなく，機能指向のデ 
一夕.フロー. ダイアグラム（以下， DFD と略す）を用いて問題を記述してみることです. 
図4 . 11の流れ図で示した問題を DFD で記述し直したものを図4 . 14に示します. 

図 4. 14で，矢印はデータの流れを示しています.また，丸印は機能(処理）を示してい 
ます. DFD では，機能は入カデータを出カデータに変換する処理としてとらえられてい 
ます. DFD によって，問題内のデータの流れとその変換過程としての機能を明確に表現 
することができます.手順を表現する流れ図との違いをよく吟味してください. DFD に 
は，初期設定，終了処理，トランザクションのタイプを判別する選択手順， EOF を条件 
とする繰返し手順といったものは一切表現されていません. DFD で表現されているのは， 
データの流れと機能であり，それによってブログラムで行うべきことが明確に理解できま 
す. 

DFD をもとにモジュール化を図り，構造的に表現したものが図 4. 15です.図 4. 15に表 
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現されているモジュールは，それぞれ単一機能を実行するようになっています.先述した 
ように，最適なモジュール化は，モジュールに機能的強度をもたせることです. 

機能的強度モジュールは，問題解決や変更をそのモジュールだけに局所化することを可 
能にします.図4.15で，トランザクション A の変更は「トランザクション A の処理」モ 
ジュールだけで考えることができ，ほかのモジュールへの波及効果を少なくします.ほか 
への影響が少ないということは，それだけモジュール強度が強いことを意味しています. 

〔3〕連絡的強度をもつモジュール 

最後に，連絡的強度について説明しておきましょう.連絡的強度は，本質的には，手順 
的強度と同じです.すなわち，問題解決のための手順を基本としてモジュール化していき 
ます.したがって，1つのモジュール内に複数の機能を含んだり，単一機能の一部を含ん 
だりします. 

連絡的強度が手順的強度と異なる点は， モジ ュール内の機能がデータの使用に関して互 
いに関連し合っていることです.たとえば， モジュール 内のすべての機能が同じ情報を参 
照しているような場合です.最初の機能の出力が2番目の機能の入力になり，2番目の機 
能の出力が3番目の機能の入力として使われるといったものがこれに該当します.たとえ 
ば，入カトランザクションを読み取り，その妥当性をチヱックし，妥当であればデータべ 
ースに蓄える機能を1 つのモジュールに まとめたものは連絡的強度 モジュール とみなすこ 
とができます(図 4.16). 

連絡的強度は，同じデータに関して関連し合った手順ということで，単なる手順的強度 
より強度的には強くなります. 


図 4. 16連絡的強度モジュールの例 


入力 x を読取る 
x の形式チ x ックを行う 
IF エラ - THEN 

エラー •メ ッ セージを 書出す 

ELSE 

X を入カファイルに書出す 
x を合計域に加える 
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コラム C 

C ++ 言語 

C + + 言語は， C 言語の後継言語として注目されています. C + + は， C 言語のスーパー 
セットとして米国べル研究所で開発されました. 

C 言語がもっている効率のよさや可搬性は， C + +でもそのまま生かされています. 
C ++ 言語では， C 言語で記述できることはすべて記述できますし， C 言語しかもっていな 
い新たな機能ももっています.そのなかでの代表的な機能としてクラス機能があります.ク 
ラス機能によって，設計上の重要な概念である情報隠匿の概念が実現できることになります. 

情報隠匿の概念は，最近注目されているオブジェクト指向プログラミングでもいかされて 
います. 


プログラムの構造化設計における1つの重要な目標は，モジュール化に際して，機能的 
強度モジュールか情報的強度モジュールのどちらかになるようにすることです.これらの 
強度をもつモジュールは，モジュールの独立性を最大にし，プログラムのエラーを減少さ 
せます.また，変更や追加をやりやすくし，プログラムの拡張性を高めます.さらに，こ 
のプログラムあるいは今後作成されるプログラムで，モジュールの再使用の可能性を高め 
ることになります. 
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コラム D 

情報隠匿の概念とクラス機能 

C + +言語は，設計時の情報隠匿の概念を実現させるためにクラス機能をもっています. 
情報隠匿の概念とは，局所的にしか使わない情報は，関係のない他の部分から操作できな 
いように，隠してしまい，誤まった操作から情報を守ります.これはモジュール設計時にブ 
ラック•ボックス化を可能にし，モジュールの独立性を高めます.結果として，変更を局所 
化し，保守作業をやりやすくします.また，データのセキュリティを高めることも可能にし 
ます. 

クラス機能は，この情報隠匿の概念を次のような形で実現させます. 
class datastruct 
{ 

int x , y , z ; 

public ; 
int s , t , ii ; 


この例で， 

class datastruct 

はクラスの宣言部の最初の行であり， class はクラスを宣言するためのキー用語， data ¬ 
struct は構造体名です. 

この行から public ; の部分までが非公開部 (Private Part ) であり，残りの部分が公開部 
(Public Part ) です. 

非公開部のデータ（この例では X ， y ， z ) は，メンバ関数しかアクセスできません.一方， 
公開数のデータ （ s ， t ， u ) はどこからでもアクセスできます. 
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5. モジュール間結合度を弱 < することを 
考えよろ 


モジュール 強度は，1 つのジュール 内部の関連性に ついての 尺度であり，関連性が強い 
ほどそのモジュールの 強度は強く，独立性が高いと考えるものでした. モジュールの 独立 
性に関するもう1 つの 尺度は，モジュール間結合 度です (図 5.1). 

モジュール 間結合度は， モジュール 間の関連性について考察するものです. モジュール 
間の関連性が弱いほど，個々の モジュールの 独立性が強くなるわけですから，結合度が弱 
いほど設計としては好ましい結果になります(図 5.2). 

モジュール間の結合の仕方としては，表 5.1 のような六つのタイプが考えられます.表 
5.1 では，結合度の強いものから弱いものへと上から下への順でならべるように設計する 
ことか望ましいのです.結合度の強弱は，モジュールの エラー 傾向，テストの困難 さ，モ 
ジュールの再使用性，保守性などの要因に対して相対的にどのような効果をもっているか 
で判定します. 


図5 . 1モジユール独立性の尺度 


モジュール A 



モジュール強度： 

特定モジュール内の構成要素 
間の関連性の強さを表す尺度 


モジュール間結合度： 

複数モジュール間の関連性の強さを 
表す尺度 
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図 5. 2結合度にもいろいろあって… 



強い結合度 



弱い結含度 


表 5.1 モジュール結合度一覧 


種類 

定 義 

特 徴 

内 容 

• 他のモジュールの内部を®;接参照する. 

• CALL ではなく直接ブランチ 

(アセンブリ言雄） 

. 他のモジュールの変更に彩響される. 

共 通 

•いくつかのモジュールが同じ大域的データ項目（異 
種）を参照する. 

•ブログラムが読みにくい（パラメータで指定され 
ない 

. 他のモジュールの変更の彩響をうける. 

• あとから利用しにくい. 

(共通域データの SAVE / RESTORE ) 

• 不必要なデータ定義のわずらわしさと不用意な使 
用. 

外 部 

•いくつかのモジュールが同じ大域的データ項目（同 
種）を参照する. 

. ブログラムが読みにくい. 

• あとから利用しにくい. 

• 不必要なデータ定義. 

制 御 

• 他モジュールの論理を制御するパラメータをわたす. 

• 論理的強度になりやすい. 

スタンブ 

• 使用しない一部のデータを含むデータ構造をパラメ 
ータによって受渡しする. 

• レコード内の無関係な変更に彩®される. 

•必要以上にデータをさらす. 

.ブラック.ボックス化が可能. 

• 統みにくさや利用しにくさは解消. 

データ 

• パラメータによる同種のデータ項目の受渡し. 

•ブラック.ボックス化が可能. 

•再使用性が大きい. 

• 無関係なデータをさらさない. 

. 結合の範囲が小さい（関係する2モジュールのみ） 
•パラメータ.リストが長くなったときのわずらわ 
しさがある. 












5.1 結合度が強くなってしまうモジュール化は，どのような時におきるのだろうか91 

結合度について考えるときは，それがモジュール間の関連性を記述するものなので，複 
数のモジュールが対象になります.モジュール A がデータ結合であるというようないい 
方は意味ありません.モジュール A と B がデータ結合であるといういい方になります. 

5.1 結合度が強くなってしまうモジュール化は， 

どのような時におきるのだろうか 

〔1〕内容結合になるモジュール 

モジュール強度と同様に，もっともよくないケースを考えることで，結合度の面からや 
ってはいけないことを理解し，ひいては望ましい型を考察してみたいと思います.「内容 
結合」は，2つのモジュールで一つが他の内部を直接參照したり，一部のルーチンを共有 
したりする結合の型です（図 5.3). この場合，一方のモジュールの変更が他のモジュール 
に影響をおよぼすことになります.変更の波及効果が大きくなればなるほど，品質面での 
保証が難しくなり，ソフトウェアの信頼性に問題が出てきます.アセンブリ言語などで， 
ブランチ命令で直接他のモジュールの部分へ制御を移すことによって，このような結合の 
型を発生させることができますが，さいわいなことに， FORTRAN や C 言語を通常の方 
法で使用してプログラミングをしているかぎり，内容結合が発生することは，ほとんどあ 
りません. 

〔2〕共通結合になるモジュール 

図 5. 3内容結合の概念 

モジュール A 


モジュール巳 


図5 .4 共通結合は図書館のようなもの 
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「共通結合」は，結合度の強さについては内容結合についで強く，設計上あまり好まし 
い型ではありません.しかし，現実にはソフトウェアがこの型の結合度によって作られる 
ことはよくあります.強度における論理的強度と同様に，それを必要とする強い動機が存 
在するからです. 

共通結合は，共通域にあるデータを参照する複数のモジュール間で発生する結合の型で 
す(図 5.4). 図 5. 5はその例を示しています.この例では，共通域に， X ， Y，Z の 3 つの 
データ構造を有しています.データ構造は，異種の いくつかの データが集まって論理的な 
1 つのグループ（レコード） を形成した ものと 考えて下さい. 

この共通域のデータを3 つの モジュール A ， B ， C が共通しています.ただ， A は X，Y 
だけを使用し， Z は使用しません.一方， B は Y ， Z を使用し， X は未使用， C は X ， Z を 
使用し， Y を使用しません.こういった場合でも，ほとんどの言語では，モジュール A ， 
B ， C に共通域のすべてのデータ（使用，未使用にかかわらず）を宣言する必要があります. 
共通結合という名前は FORTRAN の COMMON 命令にあやかってつけられたものです. 
COMMON 命令は，データ集合を特定の共通域に貯え，そこにあるデータを複数のモジ 
ュールで参照できるようにする命令です.図 5. 6はその例を示しています.この例で，モ 
ジュール MODA ， MODB ， MODC は COMMON 域にあるデータ X ， Y ， Z を介して共通 
結合しています. 

C 言語では，複数個の外部変換を介して結合しているモジュールは共通結合になります. 
たとえば，図 5. 7のようなプログラムを考えてみましょう. 

このプログラムで， x ， y ， z は外部変数であり，すべてのモジュール（関数)で広域的にア 
クセスできます.外部変換を介して結合しているモジュールは共通結合です.このプログ 
ラムでは， main , modi , mod 2 は共通結合になります. 

図 5. 5共通結合の概念 


モジュール B 



トート… 1 「••（共通域データ） 
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図 5. 6共通結合の FORTRAN モジュール 


MAIN MODA 


COMMON X ， Y , Z 


SUBROUTINE MODA ( Rl , RZ ) 

CALL MODA ( Rl , R £) 


COMMON X, Y. Z 

CALL MODB ( R 3. R 4) 


R 1 二 X + Y 

CALL MODC ( R 5, R 6) 


R 2= X — Y 

END 


RETURN 

END 


MODB 

SUBROUTINE MODB ( R 3. R 4) 
COMMON X . Y . Z 

R 3= Y+Z 

R 4= Y — Z 

RETURN 

END 


MODC 

SUBROUTINE MODC ( R 5. R 6) 
COMMON X . Y . Z 

R 5= X+Z 

R 6= X-Z 

RETURN 

END 


図 5.7 C の外部変数は外部結合 
となることもある 


int x, y, z ; 
main () 

{ 

extern int x, y, z ； 


modl() 

{ 

extern int x, y, z ； 

} 

mod2() 

{ 

extern int x, y, z ； 
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►共通結合のデメリット 

さて，共通結合はなぜ内容結合についで結合度が高いとみなされるのでしょうか.それ 
は，一般的には，つぎのような理由によります. 

⑴共通域のデータの一部が修正されたとき，共通域參照の全モジュールが影響をうける. 

(2) 共通域のデータは，一部のデータを使用しないばあいでも，モジュール内です ベて 宣 
言しておかなければならない(特に FORTRAN の場合).これは，モジュール内に本来不 
必要なデータをもちこむことになり，取扱いをわずらわしくし，また，まちがった使用を 
発生させる可能性をもっている. 

(3) 共通域のデータは，モジュール間のインターフヱースに現れないので，モジュールの 
読みやすさをそこねる原因になる. 

(1) に関しては，図 5. 5で，モジュール A の都合でデータ X の長さを変更したとき，本 
来その変更に無関係であるモジュール B ， C がその変更の影響をうけ，少なくともコンパ 
イルのし直しが必要になります.まずいばあいには， B ， C は A の変更により，共通域の 
データを使えなくなったり，変更したのを知らずにそのまま使用して，思わぬトラブルに 
まきこまれてしまうこともあります.共通域のデータを数百個ものモジュールで参照して 
いるプログラム も世の中に存在します.共通域のデータの 一部の 変更が，このような プロ 
グラムではどんな意味をもつのか，ちょっと考えただけでもぞっとしますね.ソフトウェ 
アの信頼性の面からみて，これひとつとっても，共通結合があまり好ましくないことがわ 
かっていただけるでしょう. 

(2) の問題に関しても，本来不必要なデータをもちこむことは，ソフトウヱアをわずら 
わしくし，データの安全保護の面からも好ましい状態ではありません. 

これらの問題点は，図5 . 6に示した FORTRAN モジュールに対してはそのまま当ては 
まります.しかし， C 言語の場合はやや趣が異なります. 

C では図 5.7 のように， FORTRAN のような COMMON 命令は使用しません.共通デ 
一夕を使用する各 モジュール 内で COMMON に該当するような宣言もしません.各 モジ 
ュールで 共通のデータかどうかは，プログラムの文脈上から決まることであり，特別の宣 
言はありません.（図 5. 7では外部変数であることを明確にするため，あえて宣言してあ 
ります).これは少なくとも， COMMON のように，各 モジュールで 不必要なデータまで 
宣言する必要がないことを意味しています.その意味では， C の場合は共通結合というよ 
りは，この後述べる外部結合と考えた方がよいでしょう.ただ，基本的には， C での外部 
変数はどのモジュール（関数）でも使用可能ですので，不本意な使用のされ方をする危険性 
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は存在します.すなわち，情報隠匿の概念は実現できません. C の上位言語である C + + 
では情報隠匿の概念を容易に実現できます.そのためには，クラスを使用することになり 
ます. 

class xyz 

{ 

int x ; 
int y ; 
int z ; 
public : 
void modA (); 
void modB ()； 

} 

この例は， xyz という名前のクラスを定義しています. class ステートメントから public 
までの間に宣言されたものはブライベートなものであり，このクラスのなかでしか使用で 
きません.ここでは，データ x ， y ， z がこれに該当します. 

X ， y ， z はこのクラスのなかで宣言されているモジュール（関数 ) modA , modB でしか使 
えません . 

(3) に関しても，図 5. 8のような例を考えていただければ，指摘した点が納得してもらえ 
るものと思います.図 5.8 は C 言語で書いたプログラムの一部ですが，この例で while は 
何回繰り返すのかを調べようとしたとき，すぐ理解できるでしょうか.繰り返し条件を指 
示している変数 count が外部変数として宣言されていれば，おそらく，関数 funcl ， 
func 2， func 3 のどれかが count の値を更新しているのでしょう.しかし，それは funcl ， 
func 2, func 3 を全部調べなければわかりません.このように，データを共通域に貯えて 
使用することは，モジュール間のインター フヱース 上にその データが あらわれないので， 
処理のしかたが判然とせず，プログラムが大変読みにくくなってしまいます.これは，ェ 
ラー発生の確率を高め， ソフ トウ エアの 信頼性をそこねる原因になります. 


図 5.8 何回繰り返すかこれでは 
わからない 


while (count < = 10) { 
fund (x, y )； 
fnucZ (y, z); 
func3 (z, x )； 
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►共通結合のメリット 

このような問題を有しているにもかかわらず，共通結合は，実際にはよく使用されます- 
その理由は， 問題解決のための重要データは，問題構造のどの部分にも関係してくるので， 
それらを必要のつど，モジュール•インターフヱースとしてやりとりするよりも，共通域 
に貯えておき，どのモジュールからも自由に参照できるようにしたほうが思考の集中がし 
やすくなるからです. 

実際，プログラム作成時に関数の引数の数が多ければ多いほど，コーディング時にわず 
らわしくなる経験は誰でも一度や二度はもっているものと思います. 

このように，共通結合は良い面と良くない面の両方をかねそなえています.共通結合を 
採用するときは，それらの点を十分検討することが大切です. 

〔3〕外部結合になるモジュール 

「外部結合」は，共通結合とよく似ています.外部結合は，外部宣言をしたデータを複 
数の モジュールで 共有するかたちの結合です.データを共有するという意味では，共通結 
合とよく似ていますが，共通結合が共通域にあるデータなら，使用してもしなくても，す 
ベて共有したのに対し，外部結合は必要なデータだけを外部宣言するのが普通なので，不 
必要なデータを共有するといったところがありません.その分だけ，共通結合より結合度 
が弱くなります.図 5. 9は外部結合の例を示しています. モジュール A ， B は同じデータ 
X を外部宣言することで共有しています.もちろん， A ， B はこのデータ X を使用して 
必要な処理を行うことになります. 

図 5. 6とちがって，使用しないデータまで宣言していない点に注目して下さい. 


図 5. 9外部結合の概念 


モジ : x — ル A 


モジ ユー ノレ巳 

外部宣言 


外部宣言 

1- 


-1 

; x 

- ^ - 


x ! 


X 
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外部結合は，共通結合とよく似ていますので，メリット，デメリットもほぼ同じですが， 
不必要なデータをさらさないので，共通結合の2番目のデメリットはなくなります. 

〔4〕制御結合になるモジュール 

2つのモジュールの間で，一方が他方に対して引数として制御情報をわたすとき，この 
2つのモジュールは「制御結合」しているといいます. 

制御情報とは，制御スイッチとか機能コードとかいったものであり，わたす側がわたさ 
れる側に対して，何らかの制御を指示します. 

これは，一方が他方の論理について何かを知っていることを意味し，結合度はそれだけ 
強いということがいえます.結合度が弱いのは相手のことを何も知らなくても自分の仕事 
ができるばあいです.すなわち，相手をブラック•ボックスとして扱えるときです.これ 
を可能にするのはデータ結合であり.そのかたちについては後の部分で説明することにし 
ます. 

►制御結合の例 

制御結合の例としては，論理的強度の部分で説明したテーブルの操作モジュールなどが 
図5 • 10論理的強度モジ ュー ルの呼出しは制御結合となる 


〈 main モジュール〉 〈 table モジュール〉 
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該当します.テーブルに対して，どのような操作を行うのか，呼出し側 ( main モジュー 
ル）は， table モジュールに対し機能コード ( fcode ) をパラメータで送ることによって指示 
します. 

この例では，呼出し側が table モジュールの操作内容を知っていて，操作のやり方を指 
示しています.このような場合，結合度がそれだけ強くなると同時に，呼び出された側 
( table モジュール)の強度は論理的強度になってしまい，その意味でもあまり好ましくな 
いのです(図5.1 0). また， table モジュールは，指示された操作の結果，エラー•コード 
( ecode ) を呼出し側に返します.これも制御情報の一種であり，エラー•コードの値によ 
って呼出し側モジュールの処理内容が異なってきます.たとえば，エラー•コードの値を 
調べて，それが正常であればその操作が正しく行われたものとして，次の正常処理へと進 
むでしょう.一方，エラー•コードの値がエラーを示すものであれば，エラー•メッセー 
ジを書出し，オペレータに次の操作の指示をあおぐといったことになるでしょう（図 5.11). 
これは，下位モジュールが上位モジュールの処理を指示していることになり，階層構造の 
基本的特性の一つをおかしていることになります.すなわち，階層構造化の一つの利点は， 
そのレベル単位で思考を集中でき，他のレベルのことはその時点では考えなくてもよいと 
いうところにあります.エラー•コードの例は，この利点をそこなう結果をもたらします. 


図 5. 11制御結合は階層構造の利点をそこなう 
〈 main モジュール〉 〈 table モジュール〉 
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5.2 結合度が弱くなるモジュール化について考えてみよう 

前節で述べた4つの結合度の型は，すべて結合度が強くなってしまう例で，その分いろ 
いろな問題点が発生することをみてきました.これらの結合度は，なるべくなら避けたい 
型です. 

それでは，望ましい結合度にするにはどうすればよいでしょうか.望ましい結合度とし 
ては，データ結合とスタンプ結合があります. 

〔1〕データ結合になるモジュール 

「データ結合」は，結合度としてはもっとも弱く，設計結果としては一番望ましいかた 
ちであり，できるだけこのかたちにもっていくように設計しなければなりません. 

データ結合とは，スカラ型のデータを引数として2 つのモジュール 間で，受渡しする型 
の結合です (図 5.13). 

「スカラ 型 データ」 という表現は，異種の データの 集まりとしての データ 構造との対比 
で 用いられており，1 つのデータ または同種の データの 集まりを意味しています. 


図 5 .12 データ結合は理想的なインターフェース 
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図 5. 13データ結合の例 


くメイン〉 <subl> 


main () 

/ 


， subl(x) 

\ 

• ノ 

/ 


y = subl(x) ； ^ 



• 

\ y 


} # 


- return (y); 


図 5. 13のように，主モジュールは，入力として x をモジュール subl にわたし，出力と 
して y をもらうことさえわかっていればそれで仕事ができ， subl が x をどのように y に 
変換するのかという論理を主モジュールが知る必要はありません.このことは， subl の 
論理を変更しても主側はその影響をうけないということであり，お互いの独立性が高まり 
ます. 

データ 結合では，2つの モジュールが 引数を介して直接連絡しあっているので，共通結 
合や外部結合がかかえていた他のモジュールの変更による影響を最小化することができま 
す.また，使用のしやすさから，再利用の可能性も高まります. 

データ 結合に対する否定的意見としては， データの うけわたしは，すべて パラメータの 
かたちで行うためにその数が多くなりすぎ，わずらわしさが増加するというのがあります. 
しかし，引数がやたらに多くなるのは，構造化そのものに問題があるのが普通です. 

また， パラメータの 指定によって モジュール 間をいきかう情報が明確になり，それによ 
って理解度が向上するといった良い面を軽視するべきではありません. 

〔2〕スタンプ結合になるモジュール 

「スタンプ結合」は，2 つのモジュール 間で必要なデータのやりとりを直接引数で指示 
する点では，データ結合と同じです.したがって，データ結合がもっている利点はスタン 
プ結合ももつことになります. 

スタンプ結合がデータ結合と異なる点は，パラメータとして指定するデータがスカラ型 
だけでなく，データ構造も含むことです（図5 .14). 複数の異種データの集まりである構造 
を一つの変数名で表現し，それを引数のなかに含めます.それによって，引数の数を減ら 
せる利点がありますが，共通結合にみられた本来不必要なデータまでうけわたしてしまう 
(データ構造内の一部のデータは使わない可能性がある）ので，それによるわずらわしさが 
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図 5. 14スタンプ結合の例 


くメイン〉 < sub 1> 



生じます. 

デ ー タ構造を用いたデータベースの使用に関心が高まっていますので， スタン プの使用 
に関心が高まっています.そして，結合度としては必ずしも悪くはありません.しかし， 
なるべくなら避けたほうが信頼性の面からは好ましいといえます. 

►スタンプ結合を避ける方法 

スタンプ結合になるのを避ける方法は，データ構造のなかで使用するデータだけをスカ 
ラ変数として指定する，すなわち，データ結合のかたちに変えてしまうことです.図 5. 15 
はその例を示しています.データ構造 x を引数でわたすのでなく， subl で実際に使用す 
る Xh x 2 だけをパラメータでわたしています.これは，10種類程度のデータ集合からな 


図 5. 15スタンプ結合をデータ結合にする方法 


〈メイン〉 < sub 1> 
















102 第 5 章モジュール間結合度を弱くすることを考えよう 


るデータ構造で，使用するのは2，3種のデータだけといったケースに有効です. 

もう1つ別の方法は，そのデータ構造をあつかうすべての処理を1つのモジュールにま 
とめてしまうことです.すなわち，情報的強度モジュールを作成することです. 

それによって，データ構造をいちいち引数でうけわたしすることなく，1つのモジュー 
ル内で処理することを可能にします. 
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6. 構造化設計に挑戦してみよラ 


前章までで，構造化設計に対する基礎知識は一応理解できたことになります.簡単に要 
約すると， 

•構造化設計のねらいは，わかりやすいプログラムを作ることにある. 

•わかりやすくすることで，作成中のエラーの発生度合を低め，変更や追加も容易にする 
♦わかりやすさを実現するには，分割，独立性，階層構造化を行う必要がある. 
♦プログラムを分割したとき，分割した単位はモジュールであり，モジュールには正確な 
定義と制御ルールが存在する 

•モジュールの独立性をできるだけ高めるには，機能的強度とデータ結合の形にするのが 

よい 

♦機能をトップ•ダウンで詳細化することで，機能の階層構造ができ，基本的には，それ 
をモジュール構造に対応させればよい. 

といったことでした. 

さて，これだけの基礎知識を頼りに，とにかく，構造化設計に挑戦してみることにしま 
しょう. 

そのために，簡単な例題をとりあげてみます.もちろん，実際の問題はもっと大きくて， 
複雑ですが，ここでは，問題そのものを正しく理解することが目的でなく，構造化設計の 
方法をまず理解することが目的ですので，問題は現実のものよりずっと簡略化してありま 
す. 

問題を簡略化することで，問題そのものよりも，構造化設計の方に考えの焦点を絞るこ 
とができます.それによって，構造化設計のなんたるかがよりよく理解していただけるは 
ずです. 
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6.1 「入カレコードの妥当性チェック」プログラム 

病院の入院患者の状態を監視するプログラムについて考えます.入院患者の脈拍，体温， 
血圧といった諸要因を随時測定し，データベースに記憶します.また，測定した値が異常 
(たとえば，体温が38度以上)であれば，看護婦に知らせます. 

ここでは，とりあえず測定した値を一定のレコード様式にして入力し，入カレコードと 
しての妥当性をチェックした後，データベースに記憶する部分に限定して考えてみること 
にします. 

—<プログラ厶仕様>- 

入院患者の測定された諸要因を入カレコードとして読取る.読取ったレコードは， 

その妥当性をチヱックし，正しければ，データベースに記憶する.入カレコードに何 
らかの エラーが あれば， エラー •メ ッセージを 打出す(図 6. 1 ( a )). 

この病院には， A と B の2種類の病陳があり， A には重症患者， B には軽症患者 
が入院している.入カレコードは，病陳ごとに別個に設計されており，その詳細仕様 
は図 6.1( b ) に示されている. 

入カレコードの妥当性チェックは，つぎのような項目に対して行うものとする. 

レコード•コード：‘丁， 

レコード. タイプ：‘ A ’ または‘ B ’ 

測定日： 

DD 31以下 
MM 12以下 
YY 91または92 
測定時間： 

TT 24以下 
MM 60以下 

患者番号：患者マスタとの比較 

測定諸要因：数字データ 

担当医師，看護婦コード：英数字データ 
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図 6.1 入カレコードの妥当性チェック.プログラムの仕様 



( a ) 概略図 


• 患者要因レコード A ( A 病棟) 


コード 

タイプ 

測定日 

測定時間 

患者番号 

脈拍 

体温 

最高血圧 

最低血圧 

皮膚抵抗 

I»-F 

看護婦トト‘ 

T 

A 

DDMMYY 

TTMM 

XXXX 

XXX 

XX.X 

XXX 

XXX 

XXX 

XXXX 

XXXX 

(1) 

(1) 

(6) 

(4) 

(4) 

(3) 

(3) 

(3) 

(3) 

(3) 

(4) 

(4) 

• 患者要因レコード B ( B 病棟） 









コード 

タイプ 

測定日 

未使用 

患者番号 

脈拍 

体温 

最高血圧 

最低血圧 

皮賴抗 

未使用 

未使用 

T 

A 

DDMMYY 

一 

XXXX 

XXX 

XX.X 

XXX 

XXX 

XXX 

- 

一 

(1) 

(1) 

(6) 

(4) 

(4) 

(3) 

(3) 

(3) 

(3) 

(3) 

(4) 

(4) 


• 患者マスタ.レコード 


コード 

患者番号 

患者名 

住所 

電話番号 

病棟 

担当医師 コ-ド 

看護婦 コ-ド 

ぺッ ド 番号 

T 

XXXX 

XXX XX 

XX XX 

XX—XX 

A または B 

XXXX 

XXXX 

XXXX 

(1) 

(4) 

(10) 

(20) 

(10) 

(1) 

(4) 

(4) 

(4) 


( b ) レコ-ド仕様 


さて，この仕様から，プログラムで行うべき機能について整理してみましょう. 
プログラム全体としては，患者の諸要因レコードを正しく読取り，データベースに記憶 
することです.そこで全体機能をつぎのようにまとめることにします. 

「患者の妥当な諸要因を得る」 

このブログラムの構造化設計を行うさいに，どこから手をつけていけばよいでしょうか. 
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いままで学んだ知識を活用すれば，構造化設計の第一歩は，プログラムを分割し，いくつ 
かのモジュールを作成し，それを階層構造化することでした.そのさい，モジュールの独 
立性をできるだけ高くすること，そのためには，モジュールを単一機能としてまとめるこ 
とでした. 

このような方針で，プログラムをモジュールに分割するためには，先程のプログラムの 
全体機能をトップ•ダウンで展開し，機能の階層構造を作り，それをモジュール構造に対 
応させればよいこともすでに学びました. 

そこで，プログラムの全体機能 

「患者の妥当な諸要因を得る」 

はどのように機能展開できるかを考えてみましょう.まず，問題仕様をよく読むことです. 
それによってこの全体機能を行なうためには必要な機能の概要が把握できます.思いつく 
ままに，おもなものをあげればつぎのようになります. 

• 患者のマスタ•レコードを I 壳 取る 
• 患者の諸要因を読取る 
•レコード様式の妥当性をチヱックする 
•エラー •メッセージを 打出す 
• レコードをデータベースに 記憶す る 

こまかなところまで考えれば，まだいくつかの機能があげられるかもしれませんが，大 
きな機能はまあこんなところが常識的でしょう. 

これらのことから，機能階層図をまとめると図 6.2 のようになるでしょう.このような 
図に整理することで，プログラムで行おうとしていることが，文章で説明されているとき 


図 6. 2プログラム仕様の機能展開 


110 
患者マスタ 
ファイルを 
読み取る 


患者の諸要因 
を読み取る 


入カレコード 
の妥当性を 
チェックする 


エラ ー • メッセ 


-丄づ。 

データべース 

_ジを打ち出す 


に記憶する 
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図 6. 3モジュール番号と追加処理 


000 000 



よりも，ずっと理解しやすくなったと思いませんか.ひとつの図は千の文章より価値があ 
るというものです. 

図 6. 2では，各機能の長方形枠の上辺に3桁の番号が付けてあります.これは機能番号 
(モジュール 構造図では モジュール 番号）です.この番号を用いることで各機能を多くの機 
能のなかから識別するのが容易になります.また，番号の付け方を体系的に行うようなエ 
夫をすることで，各機能の階層構造上での位置づけを明確にすることができます.この例 
で用いた3桁の番号は，頭1桁が階層構造のレベルを表わしています.また，下1桁が0 
にしてありますが，こうしておくと後で追加があったとき，そこに有効数字を用いること 
で，全体の体系をくずさずに追加することができます. 

XX 0 


(階層レベル）（追加時に使用） 

たとえば，レベル1の110と120の機能の間に1つの機能を追加したいときは，番号と 
して115を使えば110,115,120と続き異和感がありません（図 6.3). 

もちろん，番号の付け方はこの方式だけでなく，他の方式もあります.たとえば，図 
6. 4のように，階層構造のレベルごとに番号の桁を増やしていけば，機能間の従属関係が 
大変明確になります.その他，読者の皆さんもいろいろ工夫して使ってみて下さい. 

少し話が横道にそれましたが，もとへ戻しましょう.図 6. 2の機能展開ができたので， 
これらの機能間のイ ン ターフヱース.データを定義してみます. モジュールの 独立性を高 
くするには，機能的強度にするほかに，データ結合にすることが必要でしたから. 

図 6. 2で，まず，インター フェース 1 について 考えてみます.「患者の マスター•ファ 
イルを読取る」は，患者 マスター •ファイルを読取り，読取ったファイルを親機能である 
患者の妥当な諸要因を得る」にわたす機能を行います.したがって，インターフェース. 
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図 6. 4体系的な番号のつけかた 



データは 「患者 マスター•ファイル」 になります. インターフヱース•データは 下位機能 
を基準に考えますので，この場合は出カ データと いうことになります. インターフヱース 
の入カ データ （上位から下位へわたす デー タ）は特にありません. 

インターフェース2についても，1と同様に考えることができます.「患者の諸要因を 
読取る」は，患者要因レコードを読取って，親機能にわたします.したがって，インター 
フェース•データの出力として「患者要因レコード」が定義できます.入カデータは，こ 
の場合もありません. 

インターフェース3はどうでしょうか.「入カレコードの妥当性をチェックする」機能 
は，親機能からチェックするべき患者要因レコードをもらいます.これはインターフェー 
ス2で親機能がうけとったものです.受取った要因レコードの妥当標識(エラーがなけれ 
ば〇，エラーがあれば 1) を親機能に戻します.したがって，インターフヱース•データと 
しては，入力が「患者要因レコード」，出力が「エラー項目」と「妥当標識」になります. 

インターフヱース4, 5に関しては，同じような考え方をしていけば，もう自分で定義 
できますね.練習のために少し自分で考えてみて下さい.図 6. 5に構造図とそのインター 
フェース.データの定義をまとめて示します.インターフェース.データを定義すること 
で，このプログラムで行おうとしていることが，より明確に理解できたと思います. 

さて，機能展開を続けましょう.問題仕様を詳しく読むと，このプログラムの重要な部 
分は，入カレコードのチヱックにあることがわかります. 

そこで，図 6 . 5の「入カレコードの妥当性をチェックする」機能(130)をさらに詳細に 
展開してみることにします.まず，妥当性をチヱックするべき入カレコードとして，2つ 
のタイプがあることが問題仕様に述べられています . A 病棟の患者用のレコードと B 病 
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図 6. 5インターフヱース定義 



棟の患者用のレコードの2種類です.病棟ごとにレコードが分けられているのは， A 病 
棟は重症患者用であり，そのために要因の測定もひんぱんに行われなければならず，ま 
た，測定データの値によっては，患者の状態が危険であり，すぐに担当医師や看護婦にそ 
のことを知らせる必要がでてきます.したがって， A 病棟レコードには， B 病棟には特 
に必要としない測定時間，担当医師，看護婦といったデータが特につけ加えられて いるの 
です. 

これらのことから，入カ レコードの 妥当性をチェックする機能は，2つの入カ レコー 
ド • タイプごとに妥当性をチヱックすることとして，図 6. 6のように展開することができ 
ます.この部分は，問題のキーになっている重要なところなので，もう少し詳しく分析し 
てみます.問題仕様にも，妥当性のチヱックの仕方の詳細が述べられています.特に，こ 
こで重要なのは，やはり患者番号の妥当性のチェックです.患者を監視することがこのプ 
ログラムの 目的なのですから，まず，入カ レコードの 患者番号が正しいかどうかを チェ ッ 
クすることが第一です. 

図 6.6 「入カレコードの妥当性をチェックする」の機能展開 
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図 6. 7図 6. 6の拡張 



このチヱックの方法として，患者マスター • レコードにあらかじめ登録してある患者番 
号と入力された患者番号とを比較する方式を採っています.そのため，患者マスター•フ 
ァイルを読みとる必要があります.このファイルの読取りは，図 6. 5で作成した構造図で 
は，別機能として前もって実行することになっています.そこで，「入カレコードの妥当 
性をチェックする」機能では，すでに読取ってあるマスター•ファイルのなかに，入力さ 
れた患者番号が存在するかどうかを確かめるためにファイルを探索することになります. 

この探索機能は，入カレコードが A タイプでも B タイプでも必要です.そこで，この 
機能は共通機能として独立させ，必要に応じて呼出すようにします.結果は図 6 . 7になり 
ます.これは図 6.6 の機能構造図を拡張したものです. 

入カレコードの妥当性チェックの内容をもう少し続けましょう.患者番号の他に，レコ 
ー ド•コード，レコード•タイプ，測定日，測定時間，測定諸要因，担当医師，看護婦コ 
ードといった項目がチヱック対象になっています.これらのチヱック項目は， A タイプ 
と B タイプとを比較してみれば，両タイプに共通したものと片方のタイプだけのものが 
混在しています. 

両タイプに共通した項目は，その妥当性のチェック方法も両タイプで同じですから，そ 
れを各タイプごとで行うと当然重複します.そこで，この部分を独立させ1回だけ実行さ 
せればよいように工夫します.図 6.8 に工夫した構造図を示します. 

この構造図と図 6. 7の構造図とを比較してみて下さい.図 6.7 では，上に述べたように， 
共通項目の妥当性のチヱックは210と220の両方で重複して行われることになります•コ 









6.1 「入カレコードの妥当性チェック」プログラム111 


図 6 . 8図 6 . 7の修正案 



—ディングすれば，210と220に同じパターンのルーチンが存在することになる でしょう. 
これは無駄な話です.しかし，図 6. 8では，それを避けることができます.「入カレコー 
ドの妥当性をチェック」 （130) するときは，入カレコードが A ， B どちらのタイプであろ 
うと，まず，「共通項のチヱック」 （205) を行い，その後，タイプに応じて，210，220で 
タイプ固有の項目のチヱックを行ないます. 

この方法によって，「共通項目のチェック」は コーディ ング時に1回行うだけでよいこ 
とになります.この図で，「患者マスター•ファイルを探索する」 （310) も従属機能として 
定義されていることに注意して下さい.その理由はわかりますね.そうです.患者番号の 
チェックも両タイプの入カ レコードに 共通するものだからです 

このように，図 6.8 の構造図は図 6 . 7の構造図が有していた問題点を解消します•その 
意味では，すぐれた構造図です.しかし，この図は何かおかしく感じませんか.この構造 
図にしたがってプログラムを作成した場合，おそらく，正常に稼動するはずです.それで 
は，何がおかしいのでしょうか. 

それは，この構造図を機能展開図としてみたときのおかしさです.先に述べたように， 
機能を階層構造に展開したとき，上位機能はそれに従属する下位機能の総括になっていな 
ければなりません. 

しかし，図 6. 8の構造図はそのようになっていません.たとえば，「患者要因レコード 
A の妥当性をチヱックする」は，その文章が意味するごとく，レコード A のすベての項 
目の妥当性をチェックしてはじめてそう言えるのです.図 6. 8では， A タイプに固有の垣 
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図 6. 9図 6. 8の問題点を解消 



目だけをチェックし，共通項目は同レベルの別にある隣接機能で行います.これでは，看 
板にいつわりありで，誤解をまねきやすく，ミスの原因になります. 

ここは，もう少し素直な構造図に修正する必要があります.代替案として，図 6. 9のよ 
うな構造図はどうでしょうか.「共通項目の妥当性をチェックする」を共通機能にし，そ 
れを レコード A と B の妥当性をチヱックする機能のそれぞれ(210と 220) に従属機能と 
して定義しています.こうすれば，先の問題点は解消しますね.図6.10にこの問題の全 
体構造図とイ ン ター フ ヱース•データを示します. 

6.2 構造化設計の手順を正しく理解しよう 

前節では，いままで身につけた構造化設計の知識を頼りに，提示された問題に対して， 
とりあえず挑戦してみました.そして，図6.10のような結果を得たわけですが，この経 
験をふまえて，構造化設計の手順を整理し，正しく理解することにしましょう. 
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図6.10 「患者の妥当な諸要因を得る」の機能階層図とインターフヱース最終案 
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6.2.1 基本的な手順をまず知っておこう 
►モジュール定義と機能分割 

図 6. 11は，構造化設計の手順の概要です.設計の手順の最初は，プログラムの最上位 
モジュールを定義することからはじまります.最上位モジュールの定義は，通常，そのプ 
ログラムが全体として行おうとしている機能そのものの定義になります.たとえば，大気 
汚染度を測定するプログラムの設計では，「大気汚染度を測定する」になります.また， 
先程の問題では，「患者の妥当な諸要因を得る」が最上位モジュールになります. 

最上位モジュールの定義ができたら，つぎはこのモジュールの機能を解くべき問題とし 
てながめ，どのような従属機能に分割できるのかを考えていくことになります. 

分割していくときには，ある機能を親と子といった縦の関係，すなわち階層構造の上下 
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図 6. 11構造化設計の手順 図 6. 12機能分割の技法はいろいろある 




関係に分割することと，兄弟，すなわち階層構造の同位レベルのいくつかのものに分割す 
ることの両方を考えていかなければなりません.もちろん，親子にするか，兄弟にするか 
は，問題の内容というか，機能の内容に依存します.これは前節の問題で，そのいくつか 
の例を検討しましたね.そのときには特にふれませんでしたが，機能分割にさいして使用 
できるいくつかの技法があります.源泉/変換/吸収分割，トランザクション分割，共通機 
能分割などと呼ばれている技法です.これらの技法については，この後順を追って説明し 
ていくことにします（図 6.12). 

これらのうちから，適切な分割技法を選択し適用することにより，直接従属する1組の 
モジュールが 明らかになってきます. 

►インターフエースの定義 

モジュール 間の直接従属関係が定義できれば，つぎにそれら モジュール 間のイ ンターフ 
エースを 定義します（図 6.13). インターフヱースを 定義するということは， モジュール 間 
に受渡しされる入力と出力の情報の種類を明らかにすることです（図 6 . 14 ).このことも， 
前節ですでに経験しましたね. 
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図 6. 13 モジュール•インターフヱースの定義 



このような過程を階層構造の上位から下位へと順を追って繰り返していきます.もちろ 
ん，この繰返し過程は，どこかで終了しなければなりません.もし，この分割過程をやり 
すぎると，最後は1命令しか含まないモジュールになってしまうでしょう.機能を入力か 
ら出力に変換する処理とみるかぎり，1命令でも十分機能とみなせるからです. 

しかし，モジュールを一つの命令にまで分割するのは，明らかにやりすぎで現実的では 
ありません. 

それ以上の分割をやるべきか，やめるべきかの判断は，そのモジュールをコーディング 
したときにどのくらいの命令数で書けるかを考えてみることです.一つの基準として，命 
令数が50程度の大きさであると考えられるときは，そのモジュールは，それ以上分割す 
る必要がないと思ってさしつかえないでしょう.なぜなら，普通の人なら50命令程度の 
論理ならとくに苦労せず頭に思い描けるでしょうし，思い描ける以上は，それで十分わか 
りやすい設計が実現できたということになるからです（コラム C 参照). 

6.2.2 源泉/変換/吸収分割 

解くべき問題をモジュールに分割するときのもっとも基本的な技法が源泉/変換/吸収分 
割です. 

源泉 ( Source ) とは，問題を解くための源となるもの，すなわち入力のことです.変換 
( Transform ) は，入力を変換して出力に変えることを意味しています.吸収 ( Sink ) とは， 
問題の結果を吸収すること，すなわち出力のことです. 

プログラムを設計するときの基本は，そのプログラムで解くべき問題の構造とプログラ 
ムそのものの構造とを一致させることです. 

この分割技法は，その意味で問題固有の構造を発見し，それをモジュール構造を作りあ 
げるときの基本にしようとする考えにたっています. 
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問題構造の発見のためには， データの 流れに注目し データが 問題構造のなかをどう流れ 
るかを理解することが大切です. データが 問題構造のなかを動くにつれてどう変換されて 
いくか，すなわち入力から出力へ変換される過程をつぶさに分析することで問題構造を明 
らかにし，それに対応したモジュール構造を作りあげます.結果として，モジュールは機 
能的強度をもつことになります. 

この分割技法の手順は図 6.14 のようになります. 

前節の問題を検討する段階では，この分割手順はまだ知らなかったので，かなり我流の 
機能分割をやってしまったわけですが，この手順にそって行うとどうなるのか，もう一度 
おさらいのつもりで考えてみましょう.それがまた，この手順をしっかり理解するために 
も役立つはずです. 

図 6. 14の第1ステップは，問題構造の大要を部分機能で表現することです.解くべき 
問題を，たとえば3〜10個くらいの部分機能で表現してみます.部分機能をとりあげる 
ときは，問題を データの 流れにそって分析し，主要なものをとりあげるようにします. 

このことは，実は前節で無意識のうちに行っていましたね.問題の全体機能「患者の妥 
当な諸要因を得る」を行うために，主要な部分機能として，次の5つをあげました. 


コラム E 

モジュールの大吉さ 

モジュールの大きさはどのくらいが適当なのか，本文中では50命令(行）ぐらいとしまし 
た.その理由としては二つあります. 

第一は人間が頭のなかで識別できるパターンは，個人差がありますが2 5±2 くらいだといわ 
れています . 50というのはその意味でごく平均的な人が頭のなかでロジックを描ける平均 
的な大きさだというわけです.皆さん自身の経験ではどうでしょうか. 

もう 一つの 理由は，プログラムの ソース •リストを印刷するとき，印刷用紙の1ページ内 
におさまる命令が約50だということです.プログラムを検討するとき，1ページ内にすべ 
てがおさまっていれば考えやすいですね. 

もっとも，50説には反論もあります.1，000命令くらいのプログラムをモジュールに分割 
するときは，モジュールの数は20個ですみますが，10,000命令になるとモジュールの数は 
200個になり，個々のモジュールの管理が大変になります.1個1個のモジュールの役割を 
理解するのも大変ですね.そのような場合は，実際には100〜200命令程度のモジュールが 
作られることがよくあります. 
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(1) 患者マスター，レコードを読取る 

(2) 患者の諸要因を読取る 

(3) 入カレコードの妥当性をチェックする 

(4) エラー •メッセージを 打出す 

⑸入カレコードをデータベースに記憶する 

このうち，（1)， （2) は入力機能，⑶は主要処理機能，（4)，⑸は出力機能であり，データの 
流れにそってあげてあることがわかります.これはたまたまそうなった のでは なく，人間 
が問題解決のために，その問題を分析するとき，入力—処理-^出力の過程で考えるのはご 
く自然だからなのです. 

このことをもう少し整然と整理しようとするのが，この手順の第2ステップになります. 
第2ステップでは，問題のなかの主要な入力と出カデータの流れを明確にし（図 6. 15)， 
それにそって，第1ステップでとりあげた部分機能をならべます.すなわち，問題に対す 
る DFD を作成します. 

たとえば，先の問題では，図 6.16 のようになるでしょう.このようにならべれば，問 
題のなかでは，データの流れが1つだけではないことがわかります.しかし，この手順で 
は，そのなかの主要な入力と出力のデータの流れに注目します.その観点からみれば，こ 


1116.14源泉/変換/吸収/分割の手順 


図 6. 15データの流れに注目 


① 


問題構造の大要を 
部分機能で表現する 



にきリ 

らと繰 

さなを 














118 第 6 章構造化設計に挑戦してみよう 


の問題での主要なデータの流れは，患者の諸要因を読取り，その妥当性をチェックし，安 
当であればそれをデータベースに記憶するところにあります. 

患者 マスタ •ファイルを読取ったり， エラー •メッセージを打出したりするのは，あく 
までも，この問題の主要なテーマを解決するときに付随的に出てくる入出力と解釈するべ 
きでしょう. 

► 最大抽象入力点と最大抽象出力点 

分析の第3のステップは，問題構造のなかで入力と出力に対する最大抽象点を見つける 
ことです. 

最大抽象点とは，入力または出力の抽象化が最大になる点のことであり，ここでいう 
“抽象化”とは，最初はっきりしていた入力がいくつかの処理をほどこされて，もはや入 
力とみなせなくなること，または，はじめて出力らしき形が現れることを意味しています. 
前者を最大抽象入力点，後者を最大抽象出力点と呼びます. 

これら各点を見つけ出す理由は，問題をもっとも独立性の高い複数の部分機能に分割さ 
せるためです. 

最大柚象入力点を見つけるには，第2のステップでならべた問題構造の出発点からはじ 
めて，入力の流れを見つけながら問題構造のなかに入っていくと，入カデータがどんどん 
抽象化されて，もはやこれ以上は入力とみなせなくなる点に達するはずです.そこが最大 
抽象入力点になります. 

一方，最大抽象出力点を見つけるには逆に問題構造の終点から出発し，出力の流れを見 
つめながら問題構造のなかをさかのぼっていくと，出力はだんだん抽象化された形になっ 
てきて，ついには出力の流れが最初に現れる点に到達します.ここが最大抽象出力点です. 

このことを例題にあてはめてみましょう.最大抽象入力点は，「患者の諸要因を読取 
る」と「入カレコードの妥当性をチェックする」の間になります.その理由は，前者の機 
能の実行結果として得られるのは入カデータであり，後者の機能は出力を求めるための®: 
理であるからです. 

一方，最大抽象出力点は，「入カ レコードの 妥当性をチヱックする」と 「データベース 
に入カ レコードを 記憶する」 の 間になります.後者はあきらかに出力処理であり， その 出 
力は前者機能が行われた後にはじめて姿をあらわします(図1 •17) • 

これら2つの最大抽象点を見つけ出せば，問題を3つのもっとも独立した機能，すなわ 
ち源泉（入力），変換(入力から出力へ)，吸収（出力）機能に分割できることになります•問 
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図 6. 16部分機能をデータの流れに 図 6. 17最大抽象点をみつける 

そってならべる 



題構造の開始点から最大抽象入力点までが源泉機能であり，一般的に表現すれば，入カデ 
一夕の流れを最大に抽象化したかたちで得る機能ということになります. 

つぎに，最大抽象入力点と出力点にはさまれた部分が変換機能であり，最大に抽象化さ 
れた入カデータを出カデータの最大に柚象化されたかたちに変換する機能ということがで 
きます. 

3番目は，最大抽象出力点と問題構造の終点までの部分が吸収機能であり，出カデータ 
を要求されている形で出力装置に出力する機能ということになります. 

これら3つの機能は，それぞれ単一な機能としてあらわされ，これらの機能をもった3 
つの モジュールを 最上位 モジュール （問題全体の機能）の直接従属 モジュールと して定義し 
ます （図 6 . 18). そして，最上位 モジュールと 直接従属 モジュール 間の インターフヱースも 
定義します. 

このことを例題に適用すれば，図6.19のような結果になります.この結果は，先に検 
討した構造図と多少異なっています.たとえば，図 6. 5の結果と比較してみて下さい.図 
6.5 の 結果は，源泉/変換/吸収分割を特に意識して いないので， 部分機能として同ー レべ 


図 6. 18源泉/変換/吸収モジュールへの分割 
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図 6. 19患者の妥当な諸要因を得る」の源泉/変換/吸収モジュールへの展開 



(源泉） （変換） （吸収) 


ルに5つの機能をもつています.これはこれで決して間違っているわけではないのです. 
しかし，図 6. 19の結果と較べると，やや問題の焦点がぼけている点はいなめません•先 
に検討した情報隠匿の概念からいけば，図 6. 5はこの段階としてはやや詳細情報をさらけ 
出しすぎているようです. 

その点，図 6. 19の結果は，問題の主要な入力，出力とその処理に焦点を絞っているの 
で，この問題の主機能として何を行うべきかが簡潔に表示されています. 

ただ，この例題のように，多くの問題では，主要入出力の他に別のデータの流れをもっ 
ています.例題では，「患者マスタ•ファイルを読取る」，「エラー•メッセージを打出 
す」がこれにあたります.これらの処理はさけるわけにはいきませんので，その処理のた 
めに，結果として，図 6. 5のような構造図になってしまうことはよくあります.しかし， 
マスター.ファイルの読取りやエラー•メッセージの打出しを必ずこのレベルで行う必要 
があるかというと，それは別問題です. 

特に， この 例題では， 「エラー•メッセージの打 出し」は，「入カ レコードの 妥当性を 
チヱックする」の下位機能として定義した方がよさそうです.理由は，先の情報隠匿の面 
からとインターフェース•データの簡潔さの面からです.この場合は，上位機能に対して， 
エラー 項目をわたさずにすみます. 

問題の全体機能を源泉，変換，吸収機能へ展開できれば，後は，それらをさらに分割す 
る必要があるかどうかを検討します.分割の必要があると認められれば，分割を続けます. 

もっとも，すべてのケースに源泉/変換/吸収分割技法が適用できるとは限りません•適 
用できるのは，問題の型が，入力—処理—出力になっている場合です. 

もちろん，大部分の問題はこの型に属しますので，この分割技法はそれだけ沉用性をもっ 
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図 6. 20入力/変換/出力問題の一般的構造 



Oc :出カ データ 

[ I ]:問題の内容によっては必要 

ています.この型の一般構造は図6.20のようになるので参考にして下さい. 

問題によっては，このような分割技法では解決できないものもあります.その場合は， 
他の分割技法を用いることになります. 


図 6. 21トランザクション分割 
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6.2.3 トランザクシヨン分害11 

トランザクション分割とは，入カトランザクションにいつくかの種類があり，その種類 
に応じて別個のモジュールを設けるやり方です（図6 .21). 源泉/変換/吸収分割が問題構造 
を入力，変換，出力に応じてモジュール化したのに対し，トランザクション分割は’変換 
機能のモジュールをさらに細かく分割するときによく用います. 

たとえば，3種類のトランザクション a ， b ， c を処理するプログラムでは，モジュー 
ル分割は，一般に図 6. 22のようになるはずです.この図の階層構造の上位部分の分割は， 
源泉/変換/吸収分割技法によって，下位部分はトランザクション分割技法によって分割さ 
れています.もちろん，この種の問題の前提として，トランザクションの種類ごとにちが 
った仕事を実行するものと考えています. 

トランザクション分割は，モジュールの独立性を高めます.なぜなら，たとえば，トラ 
ンザクション a を処理するモジュールは，トランザクション a の処理について注意を払 
う唯一のモジュールであり，他の種類のトランザクション b ， c については，いっさい芩 
える必要がないからです • b ， c を処理するモジュールについても同様のことがいえます. 

この分割の考え方は，実は，先の例題で経験しましたね.例題では，患者要因レコード 
A ， 患者要因レコード B がトランザクションでした.そして，入カレコードの妥当性を 
チェックする機能で，トランザクションごとにその妥当性を検討するように設計しました. 
この部分がトランザション分割です（図6.23).こうすることによって，互いに相手を意識 
することなく，それぞれのタイプごとに処理ができることになります.また，それぞれの 
トランザクションに何らかの変更があったとき，そのトランザクションの処理モジュール 
だけ忝変更すればよく，他のモジュールへの波及効果を防ぐことができます. 


図 6. 22変換機能に対するトランザクション分割 図 623 例題におけるトランザク 
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6.2.4 共通機能分割 

共通機能分割は，解くべき問題を源泉/変換/吸収分割やトランザクション分割などを用 
いて 分割していく過程で，定義したいく つかの モジュールに共通の機能を見いだせるとき， 
その機能をとり出し別個のモジュールとして定義するやり方です.そして，その共通機能 
を必要とするモジュールは，必要なときに別個に定義したモジュールを呼び出すようにし 
ます. 

図 6. 24は，その1つの例です.入力を読み取るときに何らかのエラーがあれば，エラ 
一•メッセージを打出してエラーがあったことを知らせます.また，入力が要求したデー 
夕がデータ.ファイルになければ，その旨をエラー•メッサージとして伝えます.「エラ 
—•メッサージを書出す」機能は，両者共通の機能ですのでこれを共通機能モジュールと 
して別個に定義し，必要に応じて「該当入力を得る」モジュール，または「該当レコード 
を得る」モジュールで呼び出します. 

共通機能モジュールを定義することで1個のプログラム内でおなじ機能を重複させるこ 
とを避けることができます.これはトランザクション分割と同様に，変更時にその波及効 
果を局所化できるという利点にもつながります. 

共通機能には，もう1 つの とらえ方があります.それは，1 つの データ構造やテーブル 
に関連する機能は，そのデータ構造やテーブルに関する共通機能であると考え， 一つの モ 
ジュール内ですベて処理するようにします.これは情報隠匿を可能にし，やはり，変更の 
波及効果を局所^:できる利点があります.この考えで定義したモジュールは，強度的には 
情報的強度をもつことになります. 

第4章で論じた大気汚染度テーブル(表4 .2) に関するすべての機能を1つのモジュール 
で処理するようにした例(図4 .4) は共通機能分割になっています. 


図 6. 24共通機能分割の例 
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6.3 患者監視プログラム 

構造化設計の正しい手順が理解できたことと思います.そこで，再び元に戻って，本章 
の冒頭でとりあげた患者監視プログラムを全体のまとまった問題として構造化設計してみ 
ることにしましょう. 

6.1 では，種々の分割の仕方をみるために，この問題の入力部分をかなり脚色して検討 
しました.実際には，患者の諸要因は，患者が寝ているベッドにそなえつけたアナログ装 
置によって直接読取ることになるでしょう（図 6.25). 

6.3.1 問題の仕様 

—《患者監視プログラ厶》- 

病院の患者を監視するプログラムを設計する.各患者はアナログ装置によって監視 
される.このアナログ装置によって，脈拍，体温，血圧，皮膚抵抗といった要因を測 
定する.プログラムは（各患者に対して指定された)丄定時間間隔でこれらの要因を読 
み取り，データベースに記憶する.各患者の各要因に対する安全範囲は，前もって規 
定されている（たとえば，患者 X の正常な体温は36.6〜37.5。(：の範囲というように）. 

ある要因が患者の安全範囲をはずれたとき，あるいはアナログ装置が正常に作動しな 
かったときは看護婦控室に通知される.なお，患者ごとの監視時間間隔のリスト，患 
者番号とベッド番号の対応，患者ごとの安全範囲データの3つは，あらかじめファイ 
ルとして準備されている. 


図6 .25 患者 監視 システム 
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図 6. 26 「患者監視プログラム」の問題構造 

( 諸要因を者要因を u 危険要因を u 看護婦に、 
、読取る記憶するみつけるらせる） 

最大柚象入力 t 最大柚象出力 

データ 中央変換 デ-夕 


6.3.2 問題の分析 

すでに理解したように，複合設計の最初のステップは問題構造の概略を把握するために, 
問題仕様から部分機能をいくつか取り出してみることです. 

そして，それらを主要な入出カデータの流れにそってならべてみることです.この問題 
の主要な入力は，アナログ装置から読み取られる患者の諸要因（体温，脈拍など）でしょう 
し，出力は患者に異常が発見されたときの看護婦への警報です.したがって，とりあげた 
部分機能をこれらのデータの流れにそってならべた結果は，図 6. 26のようになります. 

► 最大抽象点とモジュール定義 

また，最大抽象点は，入力に関しては読み取られた患者の諸要因が安全範囲データと比 
較できるような形式になる点です.出力に関しては，患者に対する危険要因（安全範囲外 
のデータが発見された要因）が出力になるわけですから，それらが最初の形であらわれる 
ところです.図 6. 26にこれらが同時に示されています. 

ここまで分析がすすめば，モジュール構造の設計を始めることができます.まず，トッ 
プのモジュールの機能は，解くべき問題そのものを機能的に表現したものですから，「患 
者の監視を行う」になります.そしてそれらに直接従属するモジュールとしては，源泉モ 
ジュールとして「患者の諸要因を得る」，変換モジュールとしては「危険要因をみつけ 
る」，吸収モジュールとして「危険要因を看護婦控室に知らせる」が定義できます(図 
6.28). 

これらの モジュール 間の イ ン ターフェースも あわせて図 6. 27 に 示して あります. 源泉 
モジュールでは一般に 親 モジュールから もらう入カ デー タはあり ません.出カ データは も 
ちろん読み取った患者の諸要因です. 

変換モジュールでは，源泉モジュールから親モジュールへわたされた患者の諸要因を逆 
に親モジュールからもらうことになります.そして危険要因がみつかったときはそれを親 
モジュールにわたします.入力を出力に変換するために，変換モジュールは読み取られた 
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図 6. 27 モジュールのトップ構造 



諸要因とあらかじめデータベースに貯えておいた安全範囲データとを比較することになり 
ます. 

吸収モジュールでは，患者番号とその危険要因を親モジュールから入力としてもらい， 
それを看護婦控室の端末装置に出力します.吸収モジュールから親モジュールへわたす出 
力は一般にはありません. 


図 6. 28 「患者の諸要因を得る」の分割 


患者の監視 
を行う 




へ 




患者の諸要 
因を彳辱る 


危険要因を 
みつける 


危険要因を 
看護婦室に 
知らせる 



入 

出 

1 

なし 

体溫，脈拍，血圧， 
皮濟抵抗，患者番号 

2 

体温，脈拍，血圧， 
皮濟抵抗.患者番号 

危険要因の名前と 
値のリスト 

3 

患者番号， 

危険要因の名前と 
値のリスト 

なし 
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►源泉モジュールの分割 

つぎに，源泉モジュール「患者の諸要因を得る」をもう少し細かく分割してみましょう. 
問題仕様からこの機能は3つの部分機能からなりたっていることがわかります. 

♦つぎに監視する患者をきめる（患者ごとに指定された一定時間間隔にもとづく）. 

•アナログ装置から諸要因を読み取る. 

• 読み取った諸要因をデータベースに記憶する. 

したがって，図 6. 28のようなモジュール展開を行うことができます.図 6. 29にはモジ 
ュール 間イン ター フ ヱース も定義してあります.入出カデータの個々についてはとくに説 
明するまでもなく理解してもらえると思いますが，インターフェース番号5の出力，「読 
取り エラー•コード」 についてだけ注釈しておきましょう.これは，アナログ装置が何ら 
かの理由で正常に作動せず諸要因が読み取られなかったときに，それを親モジュールに知 
らせるために設定されたものです. 

このことをさらに正しく理解するために，「正常な諸要因を読み取る」機能をもっと詳 
しく分割してみる必要があります.このモジュールでは，監視すべき患者の番号を入力と 
してもらいます.そしてそれをベッド番号に変換することが必要になります.というのは 

図 6. 29 「正常な諸要因を読み取る」の分割 



正常な諸要因を 
読み取る 

Is 

患者番号をベッド 
番号に変換する 


1° 

装置から 1 者要因 
を読み取る 


異状装置の場所 
を確認する 




I 溫警報 



入 

出 

7 

患者番号 

ベッド番号 

8 

ベッド番号 

体温，脈拍，血圧， 

皮膺抵抗， 

読取りエラ-•コード 

9 

べッド番号 

なし 

10 

出力行 

なし 
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病院に固定しているめはベッドであり，患者はそのときどきで変わります.したがって， 
アナログ装置はべッドに固有のものであり，患者に固有のものではないのです. 

ベッド番号がきまれば，そのアナログ装置から諸要因を読み取ることになります.もし 
そのときにアナログ装置が正常に作動しないときは，そのべッドの設置場所を看護婦控室 
に知らせます.この結果を図 6. 29に示します.図 6. 29， 「装置から諸要因を読み取る」 
モジュールの下辺の菱形記号は，その下の異状装置の場所を確認するモジュールが条件 
(エラーが あったとき）に応じて実行されることを示しています. 

►変換モジュールの分割 

変換モジュール「危険要因をみつける」では，先にものべたように，行うべきことは 
個々の患者に対する安全範囲をデータベースから読み取ることと，患者から読み取った諸 
要因をそれらと比較し，安全範囲外のものがあるかどうかを調べることです.したがって， 
モジュール分割を行うと図6 . 30のようになります. 

►吸収モジュールの分割 

吸収モジュール「危険要因を看護婦室に知らせる」についての分割は，とくに説明する 
こともないと思います.結果だけを図 6. 31に示しておきます. 


図 6. 30 「危険要因を見つける」の分割 




入 

出 

11 

患者番号 

体温，脈拍，血圧， 
皮膚抵抗(安全範囲） 

12 

1売み取った要因， 
安全範囲 

危険要因 


図 6. 31「危険要因を看護婦に知らせる」の分割 




入 

出 

13 

危険要因の名前と 

出力行のリスト 

値のリスト 

14 

出力行 

なし 
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6.3.3 結果に対する評価 

以上でこの問題に対するモジュール分割作業は，一応完了したことになります.この設 
計結果に対して1つの問題点があります.それは先にふれた読取りエラー • コードに関す 
るものです.この読取りエラー.コードはインターフェース5と8の出カデータとしてあ 
らわれていますが，これは一種の制御情報です. 

「装置から諸要因を読み取る」モジュールは，装置が正常に作動しなかったときのコー 
ド値を設定し，親モジュール「正常な諸要因を読み取る」にわたします.正常な諸要因を 
読み取るはさらにインターフヱース5を介して親モジュール「患者の諸要因を得る」モジ 
ュールにこのコードをわたします.「患者の諸要因を得る」は，このコードの値の結果に 
よって「監視すべきつぎの患者をみつける」モジュールを呼ぶ（エラーのとき）か，「諸要 
因をデータベースに記憶する」モジュールを呼ぶ(正常のとき）かを決定します. 

これらの事実は，これに関連する3つの モジュールが， データ結合でなく制御結合にな 
っていることを示しています.制御結合は先にのベた理由によりあまり好ましい型ではあ 
りません.そこで，先に得られた モジュール 構造の修正が必要になります.読取りエラ 
一 •コードをインター フヱー ス.データに あらわれないようにするにはどうすればよいで 
しょうか.それは読取りエラーに関連する処理を複数モジュールで行うのではなく，特定 
の モジュール 内で処理できるように分割方法を変えればよいのです. 

修正した結果を図 6. 32に示します.装置からの読取りを「つぎの患者の諸要因を読み 


図 6. 32構造の修正 











130 第 6 章構造化設計に挑戦してみよう 


図 6. 33 「患者監視ブロログラム」の全体構造 




入 

出 

1 

なし 

体温,脈拍,血圧,皮膚抵抗,患者番号 

2 

体温.脈拍.血圧.皮 f 抵抗,患者番号 

危険要因の名前と値のリスト 

3 

患者番号,危険要因の名前と値のリスト 

なし 

4 

なし 

患者番号 

6 

患者番号,体温,脈拍,血圧,皮膚抵抗 

なし 

7 

患者番号 

べッ ド 番号 

9 

べッド番号 

なし 

10，14 

出力行 

なし 

11 

患者番号 

(体溫.脈拍.血圧.皮虜抵抗)の安全範囲 

12 

読み取った諸要因，安全範囲 

危険要因 

13 

危険要因の名前と値のリスト 

出力行のリスト 

15 

なし 

体温,脈拍.血圧,皮濟抵抗.患者番号 


取る」で行うようにすることが問題解決のキーです.こうすることによって「監視すべき 
つぎの患者を見つける」モジュールを呼ぶか，親モジュール「患者の諸要因を得る」にコ 
ントロールを戻すかは自己モジュール内で判断でき，読耳又り エラー. コードをインターフ 
エース•データとして他のモジュールにわたす必要がなくなります.修正後の設計結果の 
全体を図6 . 33に示します.これらの結果が機能的強度とデータ結合の形になっているこ 
とをよく確かめてください. 
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6.4 設計結果に対する評価 

この章でみてきたように，構造化設計の基本は問題を機能的に構造化し，それをモジュ 
ール構造に対応させていくところにあります. 

それは1つの方法論とみることができますが，だからといって料理読本のようにサジー 
杯の味加減まで規定しているわけではありません.設計過程をおおまかに枠組みしたもの 
にすぎません.したがって，同じ問題を設計しても，誰が行っても同じ結果になるとは限 
りません.むしろ，異なった結果になる方が普通かもしれません. 

したがって，設計結果に対してはたしてそれが最良の結果であるのかどうかをいろいろ 
な角度から見てみる必要あります（図6.34).その場合，つぎのような観点から評価してみ 
ることができます. 

春モジュールの大きさ 
春モジュールの独立性 
春階層構造としての的確さ 

♦入出力処理の隔離とインターフヱースの簡潔さ 
♦制御範囲と影響範囲 

以下，これらの点について個々にみてみることにしましょう. 


図 6. 34設計の結果はいろいろな面から評価する 
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図 6. 35大きさはよく検討して決定しよう 



►モジュールの大きさ 

第2章で，わかりやすいプログラムにするための設計の基本方針について述べました. 
その第1は，分割の概念でした（図 6.35). 

分割することで，問題解決のために同時に考えなければならない要因の数を少なくする 
ことができます.その意味では，モジュールの大きさは小さいほうがよいと言うことがで 
きます. 

人間が一度に理解できる限界は2 5±2 通りくらいという説があります.これをモジュール 
の大きさに適用すれば，命令数で30 くらいということができます.また，プリンタ•リス 
卜の1ページ（約50命令）内におさまるくらいの大きさにしておけば，モジュールを調べ 
るとき，いちいちページめくりをしなくてよいから理解しやすいという実現的な考えもあ 
ります. 

ただ，現実に モジュール 化を行なうとき，30とか50という数は， モジュールの 大きさ 
としては，やや小さすぎるきらいがあります. 

たとえば，命令数が1000のプログラムで，モジュールの大きさを50命令とすれば，20 
個のモジュールができます.これが10000命令のプログラムになれば，モジュール数は 
200個になります.これらのモジュールをすべて独立して扱い，管理するのは大変やっか 
いな話です. 

実際には 100-200 命令の大きさのモジ ュールが 多くみられます. 

構造化設計の提唱者の一人である G . J . Myers は，命令数が2000〜3000のプログラムで 
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図 6. 36 PL / I 言語でのモジュールとセグメントの違い 



( a ) 外部手続きは単独にコンパイルできる 
(モジュールの例） 


PROCEDURE OPTIONS (MAIN ) ； 

I 

I 

I 

I 

I 

I 

CALL INIT ； 

I 

I 

l 

I 

l 

INIT ； 内部手続き 

PROCEDURE : 

I 

i 

i 

i 

END INIT ； 

I 

l 

I 

I 

i 

i 

END MAIN ； 

( b ) 内部手続きは MAIN モジュールと一緒に 
コンパイルする（セグメントの例） 


は，モジュールの大きさは40〜50命令に，10000命令以上のプログラムでは，100〜150 
命令にするよう勧めています. 

比較的小さいプログラム（たとえば，1000命令以下)では，個々に独立してコンパイル 
するモジュールよりも，分割した部分機能単位をセグメントとして扱うほうがより実際的 
と言えます. 

セグメントとは， 

參命令が語彙と しても と もっている 
馨固有の名前が ついていて 他から呼出し可能である 
の 2 つの 条件を満足する ものです. これは モジュールの 条件から 
籲単独でコンパイルできる 

という条件をとり除いたものと考えることができます. 

モジュールとセグメントを区別して考えるのは，プログラム言語によっては，それがま 
ったく違ったものを対象にするからです. 






134 第 6 章構造化設計に挑戦してみよう 


たとえば， PL / I 言語ではモジュールは外部手続きに相当しますが，セグメントは内部 
手続きに相当します.外部手続きは単独でコンパイルできますが，内部手続きはできませ 
ん.そして，これら2つの実際的な価値のちがいは，呼び出し時にデータを引数としてう 
けわたしできるかできないかという点にあります.外部手続きは引数指定ができますが， 
内部手続きはできません（図 6.36). 

このことは，内部手続きを用いるときは，データ結合でなく，共用結合になってしまう 
ことを意味しています.このことは， COBOL 言語のサブプログラムと PERFORM パラ 
グラフに対してもあてはまります. 

しかし，本書の読者の方々が多く使用されている C 言語では事情が異なってきます. 

C では，モジュールに該当するものは関数ですし，セグメントに該当するのも関数と考 
えることができます.関数を単独でコンパイルするか，そのプログラムの一部として，他 
の部分と一緒にコンパイルするかは，その関数の用途によってきまります.したがって， 

C ではモジュールでもセグメントでも，データを引数としてうけわたしできることになり 
ます. 

モジュールの大きさは，テストのしやすさにも大いに関係してきます.簡単な例で考え 
てみましょう. 

図 6. 37は比較的大きなモジュール A の論理を表わしています.このモジュールのすべ 
ての論理経路をテストするためには， 12(2 X 3 X 2) のテスト • ケースをテストする必要 
があります. 

このモジュール A を，いま，図 6. 38のように2つのモジュール B ， C に分割したとき， 
すべての論理経路をテストするためには， B が6 (2 X 3) ケース， C が2ケースになり， 
あわせて8ケースですむことになります.分岐数が多くなるほどこの差は大きくなります. 

モジュールの大きさを考える時のいくつかの考慮点について述べてきましたが，基本的 
には，モジュールは問題の機能構造に起因するものであることを忘れないでいただきたい 
と思います.モジュールの大きさは，どんな場合でも50命令とか100命令以内に収めな 
ければならないと強制的に考えるのはまちがっています. 

先にあげた数字はあくまでもおおまかな目安であると思って下さい.その目安を基準に 
して，あまりに大きすぎるモジュールは，もう少し部分機能に分割できないかどうかを検 
討してみて下さい（図 6.39). 

また，反対にあまり小さすぎるモジュールは分割しすぎでないか検討してみて下さい. 
特にそのモジュールを呼び出す親モジュールが1つしかないようなときは，親モジュール 
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図 6. 37 

すべての経路をテストするには12とおり 
のテスト • ケースが必要 



図 6. 38あわせて8とおりのテスト.ケースですべての論理経路がテストできる 




図 6. 39 

大きすぎる モジュールは 部分機能を 
別モジュールに 
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06.40小さすぎるモジュール （ B ) の統合 



との統合を検討してみて下さい（図 6 . 40). 

多くの モジュー ルから呼び出されて いるモジュー ルの場合は，統合すれば そのモジュー 
ルの部分が呼び出し モジュールに 重複して持たれることになり，保守作業であやまりをお 
かす可能性が高くなりますので気をつけて下さい（図 6 . 41). このようなときは，小さくて 
も独立したままにしておくことが得策でしょう. 

ただ，独立させておくと，それを呼び出す時のオーバヘッド時間が問題になるときがあ 
ります.呼び出し数が多ければ多いほど，それは問題になってきます. 

そのようなときの解決策は，その呼び出し数の多い小さなモジュールをあくまでも独立 
させたまま，インラインのモジュールとして，親モジュールに統合させることです 
(図 6.42). 

独立させた モジュール として扱うことで，その モジュルに 変更があったとき，一箇所の 
変更だけですませることが可能になります.もし，親 モジュールに 重複させることで統合 
してしまえば，重複分だけの変更が必要になります. 


►モジュールの独立性 

モジュールの 独立性に ついては，4 章と 5 章で詳しく検討しました.結論として， モジ 
図 6. 41多くのモジュールから呼び出されるモジュールを親モジュールに統合する 
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図 6. 42親モジュールの多いモジュールを統合するときはインライン扱いにする 





%INCLUDE 
X 


%INCLUDE 
X 


%INCLUDE 
X 


独立モジュール 


X X の修正が必要なときは 
この部分を修正する 


ュール強度は機能的強度か情報的強度に，モジュール間結合度はデータ結合にするのが望 
ましいと述べました. . 

しかし，どんなときでも必ずそのような結果になるようにしてしまうということではあ 
りません.構造化設計の真の目的は，よく考えて設計するということにあります.データ 
結合と共有結合の長短をよく理解した上で結合度を設計し，よく検討した結果が共有結合 
の方がよいとなればそれはそれでよいのです.避けなければならないのは，何の方針もも 
たずに設計することなのです(図6.43). 

ところで，定義したモジュールの強度や結合度がどのようなタイプになっているかを判 
断するにはどうしたらよいのでしょうか. 

結合度に関しては，第5章の内容をよく理解すれば，判別するのはそれほど難しいこと 


図 6. 43独立性はよく考えて 
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ではありません.しかし，強度に関しては，慣れないと判断に苦しむことがよくあります. 

強度を判定する簡単な方法はモジュールの定義文をチヱックしてみることです.たとえ 
ば， G . JL Myers はつぎのように言っています. 


參その文が重文で，コンマがあるか，または複数個動詞があれば，その モジュールは 
たぶん複数個の機能を実行している.したがって，それは手順的，連絡的，あるいは 
情報的であることが多い. 

•その文に，時間的経過に関係がある言葉，たとえば，「まず」，「つぎに」，「さ 
らに」，「..•のとき」などの言葉が含まれている場合，その モジュールは たぶん手順 
的である. 

參初期値化，消去などの言葉があれば，時間的である可能性が強い. 

籲その文の述語に単一の特定の目的語がないばあい，そのモジュールは論理的である 
ことが多い.たとえば，「すべてのデータを編集する」といった表現である. 


モジュール強度が機能的であるためには，少なくとも上のような表現がとられていず， 
文の述部にたいして明確な1つの目的語が存在することです. 

このような判定方法の他に，第4章で検討した内容をもとに，つぎのような面から強度 
の判定を行うことができるでしょう. 

• モジュール機能の記述のしにくさ 
• モジュールの複数機能の実行 
• 呼び出されたときの機能の実行数 
• 機能と入口点との対応 
• モジュール内の機能の機能的関連性 
• モジュール内の機能の手順的関連性 
• モジュール内の機能のデータ的関連性 

これらの要素と モジュール 強度との関係をまとめたものを図 6. 44に示しておきます. 
強度判定の例を簡単な具体例をもとに考えてみましょう.図 6. 45は前節でとりあげた患 
者監視プログラムの1つの設計例です.実際には，この図のバブルごとに示された個々の 
機能単位に モジュール 化することになる（すべて機能的強度になる）でしょうが，ここでは 
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図 6. 44モジュール強度の判定 


強度 

評価項目 

暗合的 

論理的 

時間的 

手順的 

連絡的 

情報的 

機能的 

モジュール機能を記述し 
にくい 

Y 

N 

N 

N 

N 

N 

N 

モジュールは複数機能を 
実行する 

Y 

Y 

Y 

Y 

Y 

Y 

N 

呼び出された時は1個の 
機能だけ実行する 

- 

Y 

N 

N 

N 

Y 

一 

各機能ごとに入口点をも 
つている 

- 

N 

- 

一 

— 

Y 

- 

機能的に関連した複数機 
能を実行する 

N 

Y 

一 

一 

一 

Y 

- 

手順的に関連した複数機 
能を実行する 

- 

一 

N 

Y 

Y 

一 

一 

データ的に関連した複数 
機能を実行する 

一 

- 

一 

N 

Y 

Y 

- 


Y :該当する 
N :該当しない 
— :無関係 


図 6. 45患者監視プログラム 
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強度判定の練習が目的ですので，図のアミ部分のようなまとめ方で4つのモジュールに分 
けたとします. 

モジュール A は「監視すべき患者を見つける」と「看護婦に知らせる」の2つの機能 
をまとめたものです.このモジュールを簡潔な言葉では定義できませんね. 

また，2つの機能は機能的にも，手順的にも，データ的にも関連性は認められません. 
したがって，このモジュールは暗合的強度になります. 

モジュール B は3つの機能「患者番号をべッド番号に変換する j ， 「患者の諸要因を 
読取る」，「危険要因を見つける」を実行します.これら3つのモジュールは出力が後の 
機能の入力として使われています.したがって，このモジュールは連絡的強度になります. 

モジュール C は1つの機能「患者の安全範囲を得る」を実行します.このモジュール 
は機能的強度をもちます. 

4番目のモジュール D は，「エラー•メッセージを出力編集する」機能と「危険要因を 
出力編集する」機能をまとめて1つのモジュールにしています.このモジュールの強度は 
いろいろな見方ができます.1つの見方は共通機能をまとめたものとして機能的強度とみ 
る考え方です.この見方があてはまるのは，エラー•メッセージと危険要因の形式が同じ 
であり，このモジュール内で編集処理がまったく同じであるときです. 

入力ごとに編集処理が異なるときは，論理的強度か情報的強度になります.入力ごとに 
入口点をもっていれば情報的強度，入口点が1つであれば論理的強度になります. 


図 6 . 46 階層構造の的確さも検討する 



担当者 
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►階層構造の的確さ 

わかりやすぃプログラムにするための設計の第3の概念は階層構造化でした. 

階層構造化することで，問題を段階的に考え，発展させてぃくことができます.特に， 
問題を機能的に階層構造化することは，先に2つの概念，分割と独立性を実現させるのこ 
とにもなります. 

その意味では，階層構造としての的確さを評価する第1の視点は，問題構造として正し 
V 、機能階層構造になってぃるかどうかです(図6 .46). 正い v 機能の展開は理解を容易にし 
ます.上位機能は下位機能の総括になってぃるかを注意してチェックする必要があります. 
機能と手順をまちがって把えてぃなぃかは，この機能の上下関係をみることで明らかにな 
ります. 

図 6. 47は，この機能の上下関係が正しく展開されてぃる例です.たとえば，「妥当な 
入カトランザクションを得る」機能は，「入カトランザクションを読取る」と「入カトラ 
ンザクションの形式をチヱックする」の2つの機能を総括した上位機能として表わされて 
ぃます. 

このような正しぃ機能展開は問題の理解を大変容易にします.一方，図 6. 48は同じ問 
題を機能的にはとらえてぃるのですが，かなり手順を意識した展開になってぃます.下位 
レベルの 左から右へ順に実行してぃくことがくみとれます. 

もちろん，この設計結果がまちがってぃる訳ではありません.手順的とは言っても，こ 
の結果を導き出すためには，おそらく，流れ図ではなく DFD で問題の分析を行なってぃ 
るはずですから，個々の単位は機能的にとらえられてぃます. 

ただ，先の図 6. 47の結果と比較すれば，わかりやすさの点で先の結果に軍杯があがるの 
ではなぃでしょうか. 

また，後の結果は制御の広がりの面でも問題を提供してぃます.根モジュール「技術情 
報を検索する」は7つのモジュールを呼び出してぃます. 7つ程度ならなんとかがまんの 
限界内ですが，これが10も20もになると大変です. 

何が大変かと言うと，それを呼び出すための制御論理が複雑になることが予想されるか 
らです.一般に，横に大きく広がりすぎてぃる階層構造は，上位モジュールでの制御が大 
変になり好ましぃ形ではありません. 

これは何もソフトウェアの設計だけの問題ではなく，何にでも当てはまりますね.たと 
えば，一人の管理者が何十人も何百人もの部下をもてば，きめ細かな管理はできませんね. 
企業が大きくなれば管理階層が増えてきます.同様に，ソフトウェアも規模が大きくなれ 
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06.47 「技術情報を検討する」の機能展開図 



No . 

入 

出 

1 


妥当な入カトランザクション 

2 

妥当なトランザクション 

該当情報 

3 

該当情報 


4 


入カトランザクション 

5 

入カトランザクション 

妥当な入カトランザクション 

6 

検索 キー 

該当情報 

7 

該当情報 

編集済出力 

8 

編集済出力 


9 

エラー •メッセージ 


10 

エラー•メッセージ 































6.4 設計結果に対する評価143 


図6.48 「技術情報を検討する」のもう一つの機能展開図 



ば階層が増えてくるのはごく自然のなりゆきです. 

だからといって，必要以上に階層を深くするのも好ましくありません.たとえば， 
図 6. 49のように，たてに深く，横にせまい階層では，一般に，モジュール間のインターフ 
エースに無® c が発生します. 

この図で， D の出力としての X を最上位の A が必要とするときは，中間の B ， C は仲 
介の労をとる必要があり，本来必要でもないデータを引数として指定しなければならない 
ことになります. 

これは作業をわずらわしくするだけでなく，プログラムの理解を困難にし， エラーの 入 
り込む可能性を大きくします. 

このように，設計の結果を階層構造的にみて妥当かどうかをチヱックしてみることが大 
切です.ただ，最も妥当な階層構造は一定の形におさまる訳ではありません.そこが設計 
の難しさでもあるのですが，最適構造は，あくまでも，問題構造に由来することをよく理 
解しておく必要があります. 


06.49 

縦に深い階層構造では B ， C はデータ父を 
仲介する必要がでてくる 
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► 入出力処理の隔離とインターフエースの簡潔さ 

入出力処理，とくに特定ファイルの操作などを1つのモジュールにまとめる方向で検討 
するのは，つぎのような点で有利です. 

•データ•セキュリティの配慮がしやすい. 

春ファイルの変更や拡張などにたいし，そのモジュールだけ変更すればよい. 

春特定の データ 構造や レコード 様式の処理を1つの モジュールに 限定することにより，他 
のモジュール 群は， レコード 全体や データ 構造を受け渡しすることが少なくなり，必要 
な個々の フィールドを 渡すだけでよくなる.結果として， モジュール 間 インターフェー 
スが簡潔になる. 

•共通結合(共通域によるデータの受渡し），スタンプ結合(パラメータでのデータ構造の 
受け渡し）が少なくなる. 

これらは情報隠匿の概念として先に説明しましたね. 

結果として，全体のモジュールが参照するデータ量の最小化をはかることができます. 
このばあい，ファイル操作を行うモジュールには，そのファイルを操作するいくつかの機 
能が含まれることになり，モジュールは情報的強度をもちます. 

このような情報的強度をもったモジュールは，機能的強度をもったモジュールとくらべ 
て優るとも劣らない価値をもつことになります.情報的強度モジュールは，最近注目され 
ているオブジェクト指向のプログラミングの考え方にそったものであるとも言えます. 

►制御範囲と影響範囲 

プログラムの 設計結果を制御範囲と影響範囲の観点から評価しなければならないことに 
関しては第1章で座席を予約する プログラムの 例をもとに詳述してあります. 

第1章の該当部分をもう一度読みなおして，その重要性をもう一度確めて下さい.プロ 
グラム設計の本質が理解できたいまは，読みなおすことで，最初考えていたよりずっとそ 
の大切さを痛感されることと思います. 
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前章でプログラムの構造化設計の基本的な手順は理解していただけたと思います.構造 
化設計は，プログラムを機能的な側面からとらえてその構造化をはかることが狙いでした. 
そして，機能構造をモジュール構造に対応させました. 

プログラムのモジュール 構造ができあがれば， つぎの 設計作業は，個々 のモジュールの 
論理の設計とその結果をもとにしたコーディングです.機能と論理の違いについては，第 
2章で説明しました.要は，機能は何を行うかであり，論理はどう行うかです.換言すれ 
ば，論理は手順であり，論理設計は モジュールで 行うべき機能をどのような手順で行うか 
を設計することです. 

この章では，まずモジュールの論理設計の方法について少し詳しく考えてみることにし 
ましょう.そして，つぎにその結果をコーディングする方法について考えてみます. 

7.1 構造化定理を用いてモジュールの論理を設計してみよう 

構造化設計の狙いは，わかりやすいプログラムを作ることにありました.モジュールの 
論理を設計するさいに考慮すべきことも，やはりわかりやすさの具現化にあります. 

わかりやすい論理を実現するためには，構造化設計のときと同様に，構造化の概念が必 
要になります.ただし，論理の構造化にさいしては，分割，独立性，階層化の考え方は必 
要ありません.かわりに，順次，選択，繰返しの3つの構造が必要になります. 

このことを詳しく理解するためには，まず構造化定理について知っておく必要がありま 
す.構造化定理は，イタリアの科学者 Bohm と Jacopini によって最初に提唱されました. 
簡単に説明すればつぎのようになります. 
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—〈構造化定理〉- 

プログラムが1つの入口と1つの出口をもつように設計されていれば（このような 
プロダラムを適正プログラムと呼ぶ)，基本的な3つの制御構造の組合せによってど 
んな論理でも記述できる. 3つの制御構造とは，順次，選択，繰返し構造のことであ 

る. 


►順次構造 

それでは，この3つの制御構造，順次，選択，繰返しとはどんなものなのでしょうか. 
まず，順次 ( SEQUENCE ) とは，文字どおり順番に実行する手順のことであり（図7.1)， 
モジュール内の命令あるいは部分機能を出てくる順に実行する型です.図 7. 2はそれを図 
示したものです.この図で， A ， B は1つの命令でもよいし，1つの部分機能と考えても 
よいのです. A ， B を部分機能と考えれば，それを実行するための特定の論理があり，そ 
れは必ずしも順次にならないかもしれませんが，それは A ， B の中のことであり， A と 
B の単位でみれば， A のつぎに B が実行されるという意味で順次なのです. 


図 7. 2順次構造 
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具体例でみてみましょう. 


① sum =0.0； 

② sum + 二 a ; 

③ sum 十 = b ; 

④ sum + = c ; 

⑤ mean = sum /3.0； 

この例は， a ， b ， c の合計と平均を求めている C 言語によるプログラムです.手順その 
ものは，特に説明するまでもないほど簡単なものですが， a ， b ， c の合計を変数 sum に， 
平均を変数 mean に求めるために，①から⑤までの命令が上から順に実行されます. 

つぎも順次型の1つの例です.ただし，この例では，命令ではなく，機能を順次に実行 
しています. 

① 正しいトランザクションを読み取る 

② 該当レコードをデータベースから探す 

③ 該当レコードを画面に出力する 

「正しいトランザクションを読み取る」ためには，トランザクションを読取り，それが 
正しいかを チヱック し，エラーがあれば エラー •メ ッ セージを書きだすといったより細か 
な機能を実行する必要があり，そのための論理は必ずしも順次ではありません(図 7.3). 
また，つぎの「該当レコードをデータベースから探す」について考えてみても，入力トラ 
ンザクションが要求しているレコードをデータベースから見つけるための論理があり，そ 

図 7. 3 

「正しいトランザクションを読み取る」 

の論理は順次と選択の組み合わせ 



トランザクションを 

読み取る 


トランザクシ 

ヨンの 

形式をチ X ッ 

クする 
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117.4 

「該当 レコードをデータベースから探す」 
の論理 



れはもはや順次ではありません(図 7.4). 

しかし，①から③までの3つの機能単位でみれば，それらは順次に実行され結果として， 
入カトランザクションが要求したレコードが画面に出力されることになります. 

►選択構造(図 7.5) 

つぎに，選択構造 (IF THEN ELSE ) についてみてみましょう.選択構造とは，2つの 
異なった命令（または機能)の実行をある条件のテスト結果によって選択する型です•図 
7.6 はその基本型を示しています.条件 P をテストし，その結果が真であれば A を，偽 
であれば B を実行します.ここで， A , B は1つの命令でもよいし，1つの機能と考え 
てもよいのです. 


図 7. 5選択 
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図 7. 6選択構造の基本型 



図 7. 7繰り返し処理 



選択構造の具体例を示します. 
if ( x < y ) 
a = b ； 
else 
a = c ; 

この例では，条件として x が y より小さいかをテストしています.そして，テスト結 
果が真 ( x が y より小さい）であれば 
a 二 b 

を実行します.一方，.テスト結果が偽 ( x は y より小さくない）であれば 
a=c 

を実行します. 

先に示した図7 . 3と図7 . 4の論理の後半部分が選択構造になっていることは，これまで 
の説明で十分理解できますね. 


►繰返し構造(図 7.7) 

3番目の構造は繰返し構造です.図 7. 8にその基本型を示します.条件 P が真である間， 
A を繰返し実行します. A が1つの命令でもよいし，1つの機能でもよいのは，順次， 
選択の場合と同じです.図 7. 8のような繰返し型は，一般に DO WHILE 型と呼ばれてい 
ます. 
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図7 .8 繰り返し （DO WHILE ) の基本型 図 7. 9繰り返し型の例 




C 言語の while 文を使用すれば，この構造は容易に表現できます. 
i =0; 

while ( i <5) 

{ 

sum += data [ i ]; 
i + + ; 

} 

上の例では， i <5 がテストされる条件です.そして，この条件が満足される間（すなわ 
ち， i が5より小さい間）， {} でく くられた命令が繰返し実行されます.この例では， 
data [0] から data [4] の値が sum にたし込まれていきます.また，繰返しが1度実行 
されるごとに i の値が1つずつ増していきます. 


図7.10 「データを処理する」の詳細論理の例 



no 


データ S 50 


yes 
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C 言語に強い方は，同じことが for 文を用いても表現できることをすでにご存知のはず 
です. 

for ( i =0; i <5; i ++) 
sum+=data [ij ; 

for 文を用いれば，繰返しを制御する論理が for 文に集中でき，制御系と処理系を分解 
して考えることが可能になります. 


► 3つの構造の組合せ 

一般に，プログラムでは，複数個の入カデータに対して同じ処理をほどこす型がよく現 
われます.その場合，論理が繰返し構造になることは容易に想像できますね.図 7.9 はそ 
れを示しています. この 例で，データの処理を行う部分をより詳細に分析していけば，そ 
の論理は順次，選択，繰返しの組合せで表現されることになるでしょう.たとえば，図 
7. 10がその一例です.データの値が100以下である間，つぎのような処理を行っていま 
す. 

春データの値が50以下であれば，カウンタ1にその値をたしこむ. 

籲 データの値が50をこえれば，カウンタ2にそのイ直をたしこむ. 

參データに 1を加える 

そして，データの値が100を越えたとき， つぎの 処理ステップに進みます.1 つの データ 
を処理する論理が繰返し処理であり，その繰返し処理の中味が選択と順次からなりたって 
います(図7.11). 


図 7. 11全体論理 


f ータ ^100$ 


/ データ 


カウンタ2 


カウンタ1 

にデータを 


にデータを 

足し込む 



























152 第 7 章モジュールの論理設計とコーディングを行おう 

このように，ある機能を処理する論理は，最終的には，順次，選択，繰返しの3つの基 
本構造の組合せで表現できることになります. 

この例を C 言語でコーディングすれば，つぎのようになるでしょう. 
for ( i = l ; i < = 10; i ++) 

for ( scanf ("% d ”， & data ; data < = 100 ;data + + ) 
if ( data < = 50) 

cntl += data ; 

else 

cnt £+= data ; 

順次，選択，繰返しの 3 つの基本制御構造を用いれば，なぜ論理がわかりやすくなるの 
でしょうか.それは goto 文を使わないで論理を作成できる点にあります. 

goto 文を使って論理を作成した場合と使わないで作成した場合のプログラムのわかり 
やすさの比較は第1章ですでに見てきましたね. goto 文の使用をやめてわかりやすくな 
った第1章の例を繰返しになりますが，ここでもう一度のせておきます. 

_>〇) 

{ 

if ( q >0) 

x = l ; 

else 

y=2; 
if ( v >0) 
z = 3; 

} 

else 

{ 

if ( w >0) 
s =4; 
else 
t = 5; 


r = 6; 
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図7 . 12ネスティングした選択構造と順次構造の組み合わせ 



再度ながめなおしてみれば，この例が選択と順次構造の組合せで作成されていることが 
わかります(図 7.12). 

順次，選択，繰返しのどの構造も，それ自体1つの入口と1つの出口をもっていること 
にすでに気付いていられると思います(図7 .13). 正規の出口以外から外部へ飛び出してい 
くことはありません.したがって，これらの構造の組合せで作成した全体論理は，結果と 
して，1つの入口と1つの出口を持つことになります. if 文や for 文を使っているかぎり， 
goto 文を使う必要はなくなります. 

goto 文を使わないとプログラムがわかりやすくなる理由は，先の例でみられるように， 
原則的にプログラムを上から下へ順次に読んでいけるからです. 


図7.13順次，選択，繰り返しの3つの構造は1つの入り口と1つの出口を持っている 
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それによって思考の混乱が防げます. goto がないがゆえに， z=3 を実行する条件は上 
から順にみていくだけですぐわかります.第 1 章の同じ論理を goto を用いて作成した例 
ではこうはいきませんでしたね.それでも，この例は比較的小さなものですので，少し苦 
労すれば goto を使用していても正解にたどりつけますが，数十ページ，ときには数百べ 
ージにおよぶプログラム•リストではそうはいきません. 

1 ページ目に出てきた goto によって 50 ページに飛んでいき，さらにそこで出てきた 
goto で 30 ページ目に戻る…といったことに何度もぶつかると，たいていの人はソース. 
リストを投出してしまうのではないでしょうか. 

このように，論理を作成するときに構造化定理をもとに行えば goto 文の使用を避ける 
ことができ，それによるメリットを享受することができるのですが，そのことにこだわり 
すぎると逆効果をまねくこともあります.ときには， goto を用いた方が論理がわかりや 
すくなることもあります.たとえば， 

(1) モジュールの終りの部分への goto. 

⑵異常終了時の ループからの 脱出. 

⑶ goto を使わないようにすることによって，モジュールのいくつかの部分に同じコー 
ド • パターンがあらわれてしまうようなとき. 

などです. 

goto のわずらわしさは，論理のどの部分へも自由に飛んでいけるところにあるわけで 
すが，飛んでいった先で論理が終了する（仕事が終わる）なら思考の混乱もなく，わかりや 
すさをそこねることはありません.このことは異常終了時の処置にもあてはまります .C 
言語では， break 文がその役目をはたしていましたね. 

また， goto 文の使用を避けるために生じた論理の重複は，将来の変更時にエラーの発 
生度合を高める原因になります. 

論理を作成するときに最も配慮しなければならないことは，そのわかりやすさを実現す 
ることにあります. goto を使わないようにすることにあるわけではないのです.このこ 
とを誤ちがえないようにして， goto の使用，未使用を慎重に検討していく必要がありま 
す.図 7 . 14 に基本制御構造のまとめを示しておきます. 
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図 7. 14基本制御構造のまとめ 



7.2 論理のわかりやすい文書化を心がけよう 

わかりやすい論理を実現させるためには，構造化定理にもとずき，順次，選択，繰返し 
の3つの制御構造の組合せで論理を表現する必要があることは理解できた思います. 
このように作成した論理を誰にでも理解できるように文書化しておくのも大切なことで 

す. 

►流れ図 

論理を文書化するとき，一番多く用いられてきたのは流れ図です.本書でも，これまで 
の部分ですベて流れ図を用いて説明してきました. 

流れ図は表現方法に自由度が大きく，どんな論理でも表現可能です.しかし，逆に，そ 
の自由度の大きさが構造化論理の表現には好ましくない結果をもたすことがよくあります. 

流れ図上での矢印はどの部分にものばすことができます.これは構造化をくずす原因に 
なります.最初は慎重に順次，選択，繰返し構造だけで論理を組立てていても，ちょっと 
した変更で，構造化をくずしてしまうような箇所へ矢印をのばしてしまいます. 

また，少しこみいった論理の構造化を流れ図で表現したばあい，論理の構造を一見した 
だけで簡単に識別することが難しくなります.図 7. 3や図 7. 4の例のようなときは簡単に 
識別できますが，図711程度になってくるとやや識別しにく くなってくることがわかる 
と思います.現実のプログラムの論理は，これらよりもずっと複雑です.それらの構造化 
を流れ図で表現するには無理があります. 
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図 7. 15 NS チャートによる論理表現 
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流れ図は，基本的に，構造化指向の文書化手法ではありません. 


► NS チャート 

そこで，構造化論理を理解しやすい形で文書化するために，流れ図にかわって， NS チ 
ヤート ( Nassi-Shnei-derman Chart) が用いられることが多くなっています. 

図 7. 15を見て下さい.これは，図7.11の流れ図で表現したと同じ内容のものを NS チ 
ャートで表現したものです. NS チャートでは，順次，選択，繰返しに対応した表現方法 
しかもっていません.図 7. 16にその基本型が示されています. 

順次構造は，順次に処理するものを矢印なしに個々の枠内に表現します(図7 . 16⑻) . 

選択構造は，条件部分を頭部に記述し，テスト結果に応じた処理部分をその下部になら 
ベて記述します(図7.16 _• 

繰返し構造は，繰返し条件を頭部に記述し，処理部分をその下部に記述します(図 7. 16 

⑹). 

図 7. 15は，この3つの基本型の組合せで表現されていることが理解できると思います. 
一番外側に繰返し構造が出てきます.この部分は10個のデータに対し1個，1個その下 


図 7. 16 NS チャートの基本表現 
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部の部分の処理を繰返します. この 繰返し処理の部分は，データを読取る処理とデータ値 
が100になるまでの繰返し処理との順次構造になっています.さらに，データが100にな 
るまでの繰返し処理は，データ値が50以下かをテストしている選択構造とデータに1を 
加える処理の順次構造になっています. 

このように， NS チャートでは，流れ図で用いたような処理の流れを示す矢印は用いて 
いません. 3つの構造に対応した記法を組合せていくことで，自然に処理手順も表現して 
います. 

構造に対応した記法を用いることで，論理構造が容易に識別できます.それによって， 
論理径路が明確になりテスト • ケースを設計するときも大変やりやすくテストも経路をな 
くすことができます. 

また，構造に対応した記法しか用いていませんので，あとで変更が生じたときも，流れ 
図のように構造化をくずしてしまうおそれはありません. 

最近はマイコンの性能向上にともない，マイコン用に作成するプログラムの規模も大き 
くなってきています.したがって，いままでのように1人ですベて作成するのではなく， 
多人数で1つのプログラムを手分けして作成する機会もふえています. 

そのようなとき，お互いの意思疎通をはかり，かつ保守のためにもわかりやすい文書化 
は欠せなくなってきています. NS チャートはそのための大変有効な手法です. 

7.3 疑似コードを用いてコーディングの準備をしよう 

「疑似コード」は構造化設計によりモジュール化したあと，モジュールの論理設計を行 
う段階で用いられます.モジュールが行うべき機能の論理を頭に思い浮かべて，一気にプ 
ログラミング言語 ( C 言語や Fortran ) でコーディングできるなら，それはそれで効率的で 
す.しかし相当の経験をつまないと最初からコーディングして構造化された論理で，間違 
いなく作成することは容易なことではありません. 

そこで，コーディングする前に一度疑似コードを用いて，論理を整理してみて自信がで 
きてからコーディングすると，それだけソフトウヱアとしての信頼性が高くなるというわ 
けです. 

疑似コードはその名前が示すように， C 言語や Fortran 言語のように現実に製品とし 
て存在するものではありません.したがって，言語固有の文法上の制約もなく，表現は自 
分の好きなようにします.自分がいちばんわかりやすい表現を使えばよいのです. 
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ただ，最低限の約束はむしろあったほうが書きやすい面がありますので，通常はつぎの 
ような約束のもとに疑似コードを使用します. 

• 論理を組み立てるときは，構造化定理を採用する. 

• 選択や繰返しの表現には， IF ， THEN , ELSE , ENDIF ， DOWNHILE , ENDDO 
などのキー用語を用いて，その部分が選択，繰返しであることが明確にする. 

• 選択や繰返しがネスト（入れ子）するときは，その階層がわかるようにレベルごとの書 
出し部分をずらす(字下げ（インデント）とよばれている）. 

• 単一機能は1行に書き，別の機能の記述は行をあらためる. 

具体例でみてみましょう. 

DOWHILE 処理済データが10個以下である 
データを読取る 

DOWHILE データ値が100以下である 
IF データ値が50以下である THEN 
カウンタ1にデータ値を加える 

ELSE 

カウンタ2にデータ値を加える 

ENDIP 

データ値に1を加える 
ENDDO 

処理済データ個数に1を加える 
ENDDO 

これは図7 . 15の NS チャートで表現した論理と同じものを疑似言語で示したものです. 
ここでは2つの繰返し論理 (DO WHILE ) がネストしています.外側の繰返し処理は入 
カデータ10個のそれぞれに対し行なわれます.内側の繰返し処理は個々の入カデータに 
対し，そのデータ値が100以下の間で行われます. 

この内側の繰返し処理の内容は，選択処理 (IF THEN ELSE ) になっています. 

これらの繰返し処理や選択処理は，それぞれ頭に DO WHILE , IF THEN ELSE のキ 
一用語を用い，制御範囲の終りには， ENDDO , ENDIF のキー用語を用いています.ま 
た，字下げのルールを併用することで，それぞれの制御範囲がより一層明 fit になり，論理 
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の読みやすさが増しています. 

疑似コードは， NS チャートと同様に，プログラムの文書化に有効です. NS チャート 
が図的であるのに対し，疑似コードは文章的で，プログラミング言語的表現に近くなって 
います. 

文書化として NS チャートを用いるか，疑似コードを用いるかはそれぞれの特徴があり， 
意見のわかれるところですが，本書では，よりコーディングに近い形式であり，モジュー 
ルの関係が明確に表現できる利点をとり，この後は疑似コードにより，論理を表現してい 
くことにします. 

7.4 モジュールのコーディングを行おう 

プログラムの設計作業は，基本的には特定のプログラミング言語とは独立しています. 
すなわち，プログラムの問題仕様を分析し，モジュール構造を設計したり，個々のモジュ 
ールの論理の構造化を考えたりする時，使用するプログラミング言語とは関係なく作業を 
すすめることができます. 

しかし， NS チャートや擬似言語で論理を設計したあと.いよいよモジュールごとのコ 
ーディング作業に入る段階になると，当然のことながら，使用するプログラミング言語を 
考慮に入れる必要があります. 

構造化定理に準じた論理にそってコーディングを行う場合，プロダラミング言語によっ 
て適，不適があるのは事実です.たとえば，大規模商用プログラム作成のときによく使用 
される COBOL 言語は，順次や選択構造は比較的素直に表現できますが，繰返し構造の 
表現に難色がありました.技術計算によく使用される FORTRAN 言語も選択や繰返し構 
造の表現に一工夫が必要でした. COBOL や FOTRAN は構造化の必要性が認識される 
以前に出現した言語ですので，構造化の思想が反映されていなかったのも止むを得なかっ 
たのです.しかし，これらの言語も構造化技法の普及にともない，次第に構造化にそった 
改良が行われるようになりました. 

その点，本書が対象にしているマイコン用のプログラムには，主として C 言語が使わ 
れることが多く，これらの言語は比較的新しい時代に出現したこともあり，構造化論理の 
表現に大変便利な命令をそなえています. 

順次，選択，繰返し構造に対する C 言語の表現方法は先述したとおりですが，確認の 
意味で図 7. 14をもう一度みておいて下さい. 
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7.5 例題をもとに考えてみよう 

構造化コーディングにつ t て理解できたところで，簡単な例題をもとに，構造化設計か 
ら構造化コーディングに進めていく様子を学ぶことにしましよう. 

—例題1:三角形の形を決める（図 7.17) - 

三角形の三辺 A ， B ， C の大きさを入力として読取る.読取ったデータをもとに三 
角形の形を決めて，つぎの該当コードを出力する. 

コード三角形の形 
0 三角形でない 

1 2〜5の形に属さないもの 

2 2辺のみ等しい 

3 すべての3辺は等しい（正三角形） 

4 直角三角形 

5 直角三角形で，2辺は等しい 


►問題の分析 

この問題のポイントは，題名が示すように，三辺のデータをもとに三角形の形を決める 
ところにあります. 

三角形の形を判定するためには，つぎのような論理が考えられます. 

⑴まず，読取った3つのデータが三角形を構成する条件を満足するかどうかを調べます. 
三角形であるためには，2辺の和が他の一辺より大きいことが必要です.すなわち， 
A + B>C 

のときは三角形を構成し， 

A+BSC 

のときは三角形にはなりません. 

⑵三角形の条件を満たすことがわかれば，次はいよいよ三角形の形を判定することにな 
りますまず，ピタゴラスの定理で直角三角形であるかどうかを判定できるのは誰でも気 
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図 7. 17三角形の形を決める 


図7 . 18ピタゴラスの定理による 
直角三角形の判定 




A 2 + B 2 = C 2 


がつくことでしょう（図 7.18). 

A 2 + B 2 = C 2 

これらの判定のためには，三辺のデータをあらかじめ昇順に分類しておく必要があります. 
(3) 直角三角形であることがわかれば，つぎに2等辺直角三角形か否かを判定します. 

三辺のデータが昇順に A ， B ， C と分類されているなら， 

A=B 

なら2等辺直角三角形であり 

A 羊 B 

ならただの直角三角形ということになります. 

⑷直角三角形でないときは，正三角形か2等辺三角形かそれ以外の三角形かを判定しま 
す. 

A=C 

であれば2等辺三角形 

A=B = C 

であれば正三角形，そうでないときはただの三角形ということになります. 

►構造化設計 

問題自体の構造は簡単です.問題仕様からみて，この問題は源泉/変換/吸収分割でごく 
簡単に構造を決定できます.この問題の主要な機能は， 
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(1) 入カデータ （3 辺のデータ）を読取ること 
⑵読取ったデータを昇順に分類すること 
(3) (2) の結果を用いて，三角形の形を判定すること 
⑷判定結果を出力すること 

です.これをデータ • フロー.ダイヤグラムで表現すると図 7. 19のようになるでしょう. 

この 図から， モジ ュ ール 構造と モジュール 間イ ンターフヱース も容易に決定できます. 
その結果を図 7. 20に示します. 

図 7. 19のデータ•フロー •ダイヤグラムは，図 7. 20のような結果ではなく，むしろ図 
7.21 のような結果を期待した方も多いと思います.最大抽象入力点の位置からみて，源 
泉モジュールは「分類ずみ3辺のデータを得る」にし，その下に読取りモジュールと分類 
モジュールをぶらさげるのが妥当でないかという考え方があるからです. 

もちろん，この考え方も間違いではありません.分類するという機能を入力機能の一部 
として把えるか，三角形の形を判定する機能の一部として考えるかの違いだけで，どちら 
の結果も，この問題に関する限り，コーディングや保守のやりやすさの観点からはさほど 
の違いはありません. 

ただ，分類機能を入力機能の一部に入れることに対しやや異和感がある気がします•こ 
の問題では，入カデータを分類する必要がありますが，一般的には，その必要のないこと 
の方が多いでしょう.分類するのは，あくまでも，三角形の形の判定のために必要なので 
あって，入力機能の本質ではありません. 

機能的にみる限り，図7.21の構造図の方がすきっりしています.これはモジュールの汎 
用性の面から重要なことです.入力機能モジュールを他のプログラムで活用しようとした 
とき，分類機能が冗長になってしまう可能性があるのです. 

その意味で，この例題の構造図は図7 .21 の方を採用することにします. 

►モジュールの論理設計 

図 7.21 のモジュール構造にもとずいて，この問題のキーになるモジュールの論理を疑 
似コードを用いて設計してみましょう. 

まず，主 モジュール 「三角形の形を決める」の論理ははつぎのようになります. 
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07.19 「三角形の形を決める」問題のデータ • フロー.ダイヤグラム 



117.20 「三角形の形を決める」問題の構造化 



図7.21「三角形の形を決める」問題のもう一つの構造図 



三角形の形を決める （ MAIN ) 
DOWHILE ( MORE - DATA ) 
3辺のデータを読取る 
三角形の形を判定する 
結果を出力する 
ENDDO 
END MAIN 
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一般に，主 モジュールの 論理は，従属 モジュールを 呼出す制御論理が中心になります- 
つ ぎに， 「三角形の形を判定する」 モジュールについて 考えてみます. このモジュール 
自体は，従属する モジュールを 呼出すだけの ごく 簡単な論理になります. 

三角形の形を判定する 
3辺の データを 分類する 
三角形の形を決定する 

END 

「3辺のデータを分類する」 モジュールの 論理は，いわゆる分類のための論理になり， 
いろいろな方法がありますが，その1つをつぎに示しておきます.論理をよく吟味して， 

3辺のデータが昇順に分類される様子をよく確かめてみて下さい.結果は 
A < B<C 
になります. 


3辺の データを 分類する 
K = 2 

DO 1=1 TO K 
DO J = I +1 TO K + l 
IF SIDE ( I )> SIDB ( J ) THEN 
DO HYPO = SIDE ( I ) 
SIDE ( I ) = SIDE ( J ) 
SIDE ( J ) = HYPO 
ENDDO 
ENDIP 
ENDDO 
ENDDO 
A = SIDE (1) 

B 二 SIDE (2) 

C = SIDE (3) 

END 
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この論理の前提として，読取られた3辺のデータが SIDE ⑴〜 SIDE ⑶に記憶されてい 
るものとしています. 

さて，最後に一番核になる三角形の形を決定する論理について考えてみましょう.基本 
的な考え方は，問題の分析のところで説明したとおりです. 

三角形の形を決定する 
IF AH - B>C THEN 

IP A 2 + B 2 = C 2 THEN 
IF A 二 B THEN 

二等辺直角三角形である（コード5 ) 

ELSE 

直角三角形である（コード 4) 

ENDIP 

ELSE 

IF A=C THEN 

正三角形である（コード 3) 

ELSE 

IF 1 A 二 B または B = C THEN 

二等辺三角形である（コード 2) 

ELSE 

単なる三角形である（コード 1) 

ENDIP 

ENDIF 

ENDIP 

ELSE 

三角形でない（コード 0) 

ENDIP 


END 
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図 7. 22大気汚染度を測定する 



以上説明したモジュールの論理が，順次，選択，繰返しの3つの基本制御構造からなり 
たっていることに注意して下さい. 

例題2 :大気汚染度の測定(図7 .22) 

もう1つの例題で考えてみましょう.第4章で一部とりあげた大気汚染度の測定問題に 
ついてまとまった形で検討してみることにします.問題の仕様は実際よりはずっと簡略化 
してあります.本書の目的は問題をより実際的に理解することではなく，構造化設計を理 
解することにあるわけですから，これで十分なのです. 


►問題仕様 

—<大気汚染度の測定》- 

規模の大きな製造工場の煙突の近くで24時間にわたって大気の汚染度を1分ごと 
に測定した.汚染度の許容測定範囲は1 ppm から180,000 ppm までの間である•プ 
ログラムとして行うべき機能は，つぎのとおりである. 

(1) 測定値は，キーボードから入力する. 

(2) 測定値は数値化してあり，すべての値は計算に使える.その範囲は1〜180,000 
ppm であり，ゼロの値があれば，それは測定装置の誤動作を示す. 

(3) 24時間のうち誤動作が起こらなかった各時間ごとの汚染度の平均値を計算する. 
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図 7. 23 「大気汚染度の測定」 
問題の印刷出力 


時間 

ppm (平均） 

1 

80864 

2 

86681 

3 

87540 

4 

75068 

5 

90222 


20 

88664 

21 

89657 

22 

91011 

23 

81726 

24 

92216 


図 7. 24 「大気汚染度の測定」問題の大要 



⑷装置が誤動作を起こした時間帯では，その時間の ppm の平均値を0 ppm にセッ 
卜し，その時間に対するすべての処理は行わない. 

⑸1時間ごとの平均値は，図 7. 23のような形式で印刷出力する. 


►問題の構造化設計 

さて，問題の分析にとりかかりましよう.分析の第一歩は，問題構造の大要をつかむこ 
とです.解くべき問題を，たとえば3〜10個くらいの部分機能で表現してみます.部分 
機能をとりあげるときは，問題をデータの流れにそって分析し，主要なものをとりあげる 
ようにします.この問題では，「汚染測定値を得る」，「1時間の測定値を集める」， 
「1時間の平均値を計算する」，「平均値を印刷する」といったところが主要機能になる 
でしよう（図7.24). 
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図 7. 25主要な入力，出カ データの 流れにそって部分機能をならべる 



測定値 


1時間の 1時間の 

測定値 平均値 


分析の第2のステップは，問題のなかの主要な入力と出カデータの流れを明確にし，そ 
れらにそって最初にとりあげた部分機能をならベてみることです. 

例題では，図 7. 25のようになります.これは第4章で説明したデータ•フロー •ダイヤ 
グラムそのものに他ありません. 

分析の第3ステップは，問題構造のなかで入力と出力に対する最大抽象点を見つけるこ 
とです. 

最大柚象入力点を見つけるには，第2のステップでならべた問題構造の出発点から始め 
て，入力の流れを見つめながら問題構造のなかに入っていくと，入カデータがどんどん柚 
象化されて，もはやこれ以上は入力とみなせなくなる点に達するはずです.そこが最大柚 
象入力点になります. 

一方，最大抽象出力点を見つけるには，逆に問題構造の終点から出発し，出力の流れを 
見つめながら問題構造のなかをさかのぼっていくと，出力はだんだん抽象化された形にな 


図 7. 26 「大気汚染 度の 測定」 のモジュールへの 展開 
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図 7. 27 「大気汚染度の測定問題」の最終結果 



大気汚染の 

測定 

/ 2 


1時間の測定 
値を得る 

1時間の平均 
値を計算する 


1時間の平均 
値を印刷する 


測定値を. 

測定値を形_ 

読取る 

式化する 




出力を形式 

出力を印刷 

化する 

する 


番号 

入 

出 

1 

なし 

1時間の測定値 

2 

1時間の測定値 

平均値 

3 

平均値 

なし 

4 

なし 

形式化されていない測定値 

5 

形式化されていない測定値 

形式化された測定値 

6 

形式化されていない印刷行 

形式化された印刷行 

7 

形式化された平均値 

なし 


ってきて，ついには出力の流れが最初に現れる点に到達します.ここが最大抽象出力点で 

す. 

このことを例題で考えてみましょう.最大抽象入力点は，「1時間の測定値を集める」 
機能と「平均値を計算する」機能の間になります.その理由は，図7.25の問題構造を開 
始点からみていけば，「汚染測定値を得る」と「1時間の測定値を集める」は入カデータ 
の流れとしてとらえることができるのに対し，「平均値を計算する」は出力を求めるため 
の処理であるからです. 

一方，最大抽象出力点は「平均値を計算する」と「平均値を印刷する」の間になります. 
「平均値を印刷する」は，あきらかに出力の処理であり，その出力は「平均値を計算する」 
機能が行われた後にはじめて姿を現します. 

これら二つの最大抽象点を見つけ出せば，問題を三つのもっとも独立した部分機能，す 
なわち源泉(入力），変換（入力から出力へ)，吸収(出力）機能に分割できることになります. 

結果を図 7. 26に示します.源泉，変換，吸収機能が単一機能として表現できている（一 
つの目的語と述語)点に注意して下さい. 

ここまで分析がすすめば，後は，源泉，変換，吸収機能をさらに分割する必要があるか 
どうかを検討します.分割の必要があると認められれば，それまでと同じやり方で分割し 
ていきます.分割の必要性に対する判断基準は，機能をコーディングするときにその論理 
が頭に思い描けるかどうかです. 

例題では，理解を容易にするために問題を簡易化しているので，これ以上の分割は通常 
必要ありませんが，分割という概念をよりよく理解するために，あえて分割をつづけてあ 
ります.分割の最終結果を図 7. 27に示します. 
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►モジ ユールの 論理設計 

図7 . 26のモジュール構造にそって主要なモジュールの論理を疑似コードによって設計 
してみましょう. 

まず，主モジュールはつぎのようになります. 

大気汚染を測定する. 

時間を1にセットする. 

DOWHILE 時間が25未満の間. 

1時間の測定値を得る. 

平均値を計算する. 

平均値を印刷する. 

時間に1を加える. 

ENDDO 

END 


主モジュールに従属している3つのモジュール「1時間の測定値を得る」，「平均値を 
計算する」，「平均値を印刷する」が1時間ごとに実行されることになるでしょう.した 
がって，この3つのモジュールを呼び出す繰返し構造が現れています. DOWHILE , 
ENDDO という用語を用いることによって，繰返し構造の制御範囲が大変明確になって 
いる点に注目して下さい.また，字下げのルールにしたがって記述されていることが，よ 
り論理を明解にしている点にも注目して下さい. 

次に，「1時間の測定値を得る」モジュールの論理は次のようになるでしょう. 

1時間の測定値を得る. 

分を1にセットする. 

DOWHILE 分が61未満の間. 

測定値をテーブルに読み取る. 

分に1を加える. 

ENDDO 


END 
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ここでも，1分ごとの測定値を1時間分読み取るために繰返し論理を設計しています. 
「平均値を計算する」モジュールの論理は次のようになります. 

平均値を計算する. 

合言十値を0にセットする. 

分を1にセットする. 

DOWHILE 分が61未満の間. 

IF テーブル 値が0 

合計域を0にセットする. 
break 
ELSE 

• 合計域にテーブル値(測定値）を加える. 

ENDDO 

合計値を60で割り平均値を求める. 

END 


最後に，「平均値を印刷する」モジュールの論理は，ごく簡単に次のように設計してお 
きます. 

平均値を印刷する. 

時間と平均値を印刷する. 


END 
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►モジュールのコーディング 

C 言語による モジュールのコーディ ング例を参考までに示しておきます.擬似 コード か 
ら C 言語に変換する作業はそれほど難しくありません. 7.4 で述べたように， C 言語は構 
造化論理を表現するのに適した命令文をもっています. 

主モジュール「大気汚染度を測定する」 

# define datasize 60 

# define endHour 24 
main() 

{ 

long ppm Laatasize]； 
int hour; 
double mean； 

for(hour = l；hour< = endHour；honr + +) 

{ 

getdata(ppm); 

mean = cmean(datasize,PPm)； 
putmean(honr,mean)； 


「1時間の測定値を得る」 

# define endMin 60 
getdata(ppm) 
long ppm []； 

{ 

int minute; 

for(minute = 0;minute < endMin；minute+ +) 
scanf(”％d”，ppm [minute]); 
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「平均値を計算する」 
cmean(datasize,ppm) 
int datasize ； 
long ppm []; 

{ 

double sum; 

sum=0.0; 

f or (i=0；i < datasize;i ++ ) 

{ 

if (ppm [i] ==0) 

{ 

sum=0.0; 

break ； 

} 

else 

snmt=ppm [i]; 

} 

return(sum/datasize); 


「平均値を印刷する」 
putmean(hour,mean) 
int hour ； 
double mean ； 

{ 

printf (” ％ 4d %6.0f/n M ,hour,mean )； 

} 

主モジュール「大気汚染度を測定する j は， 3 つの直接従属モジュール「 1 時間の測定 
値を得る」，「平均値を計算する」，「平均値を印刷する」をもっています.このコーデ 
イング例では，これら 3 つのモジュールをそれぞれ getdata ， cmean, putmean という名 
前の関数として扱っています . 主モジュールの論理はこれら 3 つの関数を 1 時間ごとに呼 
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出す繰返し構造からなりたっています. 

繰返し構造は for 文で表現しています.この箇所は while 文でも表現できますが，制御 
情報と処理情報をはっきり区別けして表現できる点を評価して for 文を採用しています. 
これによって，モジュール論理がわかりやすくなります. 

処理の基本デ ー タである測定された大気汚染度データは ppm という名前のテーブルに 
貯えます. ppm は配列で60個のデータを貯えるようになっています(図 7.28). 1分ごと 
に測定されたデータを60個貯えることにより，テーブル全体で1時間分のデータを貯え 
ます. 

各 モジュールのコーディン グ論理が先述の疑似 コー ドの論理にそっていることを確めて 
下さい.また， {} や字下げの ルールで 繰返しや選択の制御範囲を明確にしている点にも 
注意して下さい. 

各モジュールを強度的にみれば，それぞれ機能的強度になっています.また，結合度は 
データ結合になっています.すなわち，モジュール間でのデータのやりとりは引数として 
指定しています.これにより，モジュール間でどんなデータのやりとりがあるかがはっき 
りわかり，プログラムの理解度が向上します. 

たとえば， 

getdata ( ppm ) 

から，大部分の人は， このモジュール （関数)が入カデータを読取り，それを テーブル 
ppm に貯えることを理解できるでしょう.また. 
cmean ( datasize , ppm ) 

から，このモジュールが ppm の datasize 個のデータ（この場合は60個）の平均を計算す 
ることを推察するのはそれほど難しくはないでしょう. 

図7 . 28—時間の測定値を貯えるテーブル 
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もちろん，変数名や関数名をつけるとき，内容をほうふつさせるような名前にするよう 
心がけることも理解度を向上させる上で大変重要なことです. 

また，適切な コメン トをモジュールの文に付加することで理解度はさらに向上するでし 
ょう.たとえば，先に示した主モジュールの コーディング 例に以下のような コメントを追 
加すれば，わかりやすさとしては万全になります. 

# define datasize 60 /* 汚染度テーブルの大きさ*/ 

# define endHour 24 / * 測定時間の上限*/ 

main () / * 大気汚染度を測定する*/ 

{ 

long ppm [ datasize ] ; /* 汚染度テーブル*/ 

int hour ； / * 時間*/ 

double mean ; /* 平均氺 / 

I or(hour = l ； hour < = endHour ;hour + + ) 

{ 

getdata ( ppm )； / *1 時間の測定値を得る*/ 

mean = cmean ( datasize , ppm ); /* 平均値を計算する*/ 
putmean = ( hour . maen )； /* 平均値を印刷する*/ 


コーディングを工夫することで，モジュール間のデータの受渡しの数をできるだけ少な 
くすることはできます.たとえば， C 言語の場合，上の例で，モジュール間の引数として 
使用されている ppm ， datasize , hour , mean を外部変数として宣言すれば，モジュール 
の呼出しごとにいちいち数として指定する必要はなくなります. 

その場合の主モジュールは次のようになるでしょう. 

# denne datasize 60 

# define endHour 24 
long ppm [datasize ]； 
int datasize,hour ； 
double mean; 


176 第 7 章モジュールの論理設計とコーディングを行おう 


main () 

{ 

extern long ppm []; 
extern int datasize hour ； 
extern double mean ; 
f or(hour 二 l ; hour < = endHour ； hour ++) 
{ 

getdata (); 
mean = Mean (); 
putmean ()； 



ご存知のとおり，データを外部変数として宣言すれば， main とそのなかで使用される 
関数（モジュール）で共有して使用できるようになります. 

これらは結合度としてみれば，共通結合になります.第5章で検討したように，共通結 
合には注目すべきいくつかの特徴があります.まず，共有データを使用するとき，モジュ 
ール間で引数としていちいち指定する必要がないことです.この例でも， ppm は，それ 
を使用する関数が主モジュールで呼出されても，引数としては表わされていません. 

このことは， コーディング 時にいちいち引数を書く必要がなく， コーディングの 手間が 
省けることを意味しています.また，関数を呼出し，実行するときのオーバヘッド時間が 
少なくてすみます.これらの理由から，現実には，よくこの手のテクニックが使用されま 
す. 

このような利点はそれなりに価値がありますが，反面，問題点もあることに気付いて下 
さい.結合度はデータ結合にするのが最も好ましいことはすでに述べました.その主な理 
由は，データ結合にすれば，相手のモジュールをブラック•ボックスとして扱え，変更の 
波及効果を最小にできることと，データを引数として指定することにより，モジュール間 
でどんなデータのやりとりがあるかをはっきり知ることができ，それが結果としてプログ 
ラムの理解度の向上につながる点にありました. 

使用するデータを引数として指定しない場合は，たしかにコーディングの手間は省けま 
すが，わかりやすさをそこねます.先のコーディングを初めて見た人は 
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getdata () : 

という文をみても，その名前からこの関数が入カデータを読取ることを推察できても，読 
取ったデータをどこに貯えるかまではわかりません. 

その意味で， 

getdata ( ppm ) ； 

としておけば，引数として指定された ppm に入カデータが貯えられると推察することが 
できるでしよう. 

また， 

mean = cmean () ； 

では，関数 Mean がその名前から平均を計算することはわかっても，何の平均を計算す 
るのかは main をみただけではわかりません.しかし，先述したように， 


mean = Mean (datasize, ppm )； 


としておけば，配列 ppm の datasize 個のデータの平均を計算することが先の例よりずっ 
と容易に推察できることになります. 

このように，引数を指定することにより，プログラムのわかりやすさを向上させる効果 
はありますが，気を付けたいのは，引数が多くなりすぎると逆効果になってしまうことで 
す. 

たとえば， 

getdata ( a , b , c , d , e , f ， g .); 

のような文に出合ったとき，7個の引数が何を意味するかを理解するのが大変になり，か 
えって，プログラムのわかりやすさをそこねます.また， コーディング 時に引数の指定 ミ 
スといった エラーを 誘発しかねません. 

引数の数は何個が最適なのかは，その関数の処理内容とのからみもあり一概に決めつけ 
るわけにはいきませんが，一般的には，5個以内程度に収めるのがよいと思います 
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なお，この問題でいままであげたコーディング例は，理解しやすいように簡略化しあり 
ますが，実際にこのような問題をプログラミングするときは，いろいろな付随処理を考慮 
します.たとえば，各種エラーに対する処理などです.これらはすべて省略してあります 
のでご了解下さい. 
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8. コーデインク'結果をテストしよラ 


製品として世に出ていくものは，製品仕様として定められた機能を十分発揮できるかど 
うかを確かめるため，製造後に必ずテストされます. 

プログラム とてその例外ではありません.むしろ， プログラム ほど作成後のテストに力 
を入れる製品は他にないかもしれません. 

ある調査では，ソフトウヱア開発において，テストが全体作業の約半分を占めているこ 
とを示しています.この調査値は日本の企業663社のソフトウヱア開発における実績値を 
平均したものです.みなさん自身，プログラムを作成するとき，作成中はできるだけ早く 
完成させるために，我を忘れて作業に熱中してしまうものと思いますが，後で振返ってみ 
れば，その作業のなかでテストと エラー 修正に費した時間が多いのに気付かれるのではな 
いでしょうか(図 8.1). 


図 8.1 テストは楽なしごとではない 
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プログラムのテストにこれだけ力を注いでいる割には，プログラムの品質は他の製品に 
較べ，決して良いとは言えません.プログラムを稼動させた後も，しばらくの間は，思わ 
ぬエラーに悩まされるのが常です. 

それだけに，プログラムのテストは慎重に，かつ効率的に行っていかなければなりませ 
ん.特に，プログラムをモジュール分割した場合は，個々のモジュールのテスト順序がテ 
ストの効率とプログラムの品質に大きな影響をあたえます. 

この章では，この問題に焦点をあて，効率的なテスト方法について検討してみることに 
します. 

8.1 トップ•ダウン方式によるテスト方法を理解しよう 

複数個のモジュールに分割したプログラムを効率的にテストするためには，トップ•ダ 
ウン方式によるテストがよいとされています. 

そこでまず，トップ • ダウン方式によるテストとはどんな方法かを説明することにしま 
しょう（図 8.2). 

理解を容易にするために，簡単な例をもとに考えます.図 8. 3は，プログラムのモジュ 
ール構造の例を示しています.この例では， A が最上位モジュールであり，直接従属モ 
ジュール B ， C ， D を有しています.また，モジュール B は E ， F ， モジュール D は G ， 


図 8. 2トップ•ダウン方式 
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図8 .3 モジュール構造の例 



H の直接従属モジュールを有しています. 

トップ•ダウン方式によるテストでは，まず，モジュール A のテストから開始します. 
A は直接従属モジュール B ， C ， D を有していますから， A をコーディングするさい，こ 
れら3つのモジュールが A のなかで呼び出されるはずです.たとえば，つぎのような形 
式になるでしょう. 


モジュール A 

main () 

double x ， y ， z ; 
modB ( x )； 
modC ( y ); 
modD ( z ); 

したがつて，モジュール A をテストするためには， B ， C ， D のモジュールが必要にな 
りますが，この場合は，これら3つのモジュールはスタブとして扱います.スタブという 
のは，1種のダミー.モジュールのことです. 

この段階では， A をテストすることが主眼であり， B ， C ， D も同時にテストするねら 
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いはありません. A が正しく作動するかどうかがわかればよいのです.したがって， B ， 
C ， D は A のテストに支障がない程度のごく簡単なものにしておきます.たとえば，つぎ 
のような形のものをとりあえず用意します.これらは上位モジュールから呼び出され，所 
定の引数のうけわたしが行われたことを確認するメッセージを打出すだけのものです. 


モジュール B (スタブ） 
modB ( x ) 
double x ; 

{ 

printf (” modB 〇 ALLED \ n ”); 


モジュール C (スタブ） 

modC ( y ) 
double y ; 

{ 

printf”modC CALLED \ n ”); 


モジュール D (スタブ） 

modD ( z ) 

{ 

printf (” modD CALLED \ n ”）； 


このように，上位 モジュールの テストのために仮に コー ディングされたものがスタブな 
のです. B ， C ， D をスタブでなく，実際の論理にそってコーディングしたものにすれば， 
A , B , C , D が同時にテストされることになります. 

もちろん，それでもよいのですが， A ， B ， C ， D を同時にテストして，うまく動かな 
かったとき，その原因をつきとめるとき， A ， B ， C , D すべてのモジュールについて考 
えなければならなくなるでしょう. 
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これでは，同時に考えなければならない要因が多くなり混乱のもとになります.もとも 
とモジュール化のねらいは同時に考えなければならない要因の数を少なくすることにあっ 
たわけですから，テスト段階でもその精神はいかしていく必要があります. 

A をテストするときには， A だけに注意を集中し，他のモジュールのことはできるだ 
け考えないですむようにすることです.これが B ， C ， D をスタブとして扱う主な理由で 
す. 

B ， C ， D ， をスタブとして扱えば， B ， C ， D の実際のコーディングができていない早 
い時点でも A のテストが可能になるという利点もあります. 

もちろん，これらのスタブは，いずれそのモジュール本来の機能を実行するようにコー 
ディンダしなおされることになります.そのさいに，なるべく変更を少なくするためにも， 
スタブはできるだけ簡単にしておく方がよいのです. 

このようにして， A のコードと B ， C ， D のスタブを用いて A のテストを実施します. 
この 時点でのテストは，下位 モジュールが スタブとして扱われる関係上，ごく限られた 一 
部の機能のテストだけにとどまることになりますが，基本的な実行順序は確立され，その 
妥当性が検査されることになります. 

モジュール A のテストが一応終了したら，次はモジュール B のテストを行うことにな 
ります.この時点で， B のスタブは本来のコードに拡張されます.そして， B が呼び出す 
E ， F 用のスタブを作成します. 

B のテストには， B のコードとともに，テスト済の A のコードも使用します.このこ 
とは， B のテストと同時に， A の再テストをも意味します.上位モジュールは早い段階 
でテストされ，その後，下位モジュールのテスト時に何度も何度も繰返しテストが行われ， 
結果として，品質の向上がはかれることになるのです.これがトップ•ダウン方式による 
テストの大きな利点です. 

図 8.4 にトップ • ダウン方式での モジュールのテス ト順序の全体像を示してあります. 
上位レベルから 下位 レベルへ，同じレベルでは左から右への 順序で1 つずつモジュールの 
テス トを行っていく のが 原則です. 

実モジュールとスタブとの関係，スタブが実モジュールへ拡張されていく様子を図 8. 4 
から正しく読取って下さい. 

もちろん，図 8.4 に示した順序は原則であり，実際のプログラムをテストしていくとき 
は，その内容やテスト•ケース等のかねあいでいろいろな変化がでてきます. 
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一般的には，テスト順序はつぎのように考えるのが普通です. 

(1) まず，正規処理のテストを行う 

(2) 独立した エラー 処理のテストを行う 

⑶いくつかの条件が重なった時に予想されるエラー処理のテストを行う 
⑷限界処理(たとえば，テーブル.オーバフローなど）のテストを行う 

トップ.ダウン•テストの思想をいかしながら，この順序でテストを行うようにすれば， 
それぞれのプログラムでの モジュールの テスト順序が最終的に決まることになります•次 
節で，これまでにとりあげた実例をもとにこのことを考えてみることにします. 

最後に，トップ.ダウン方式によるテストの特徴についてまとめておきましょう. 

• 階層構造の最上位モジュール（主モジュール）を最初にテストできる（図8 .5). 

最上位モジュールは，一般に，プログラム全体の制御を行い，最も重要なモジュールです. 
最も重要な部分を一番はじめにテストできるのは大きな利点です.重要な部分を最後にテ 
ストし，そこで欠陥がみつかれば，それまでにテストしたものがすべて無駄になってしま 
う可能性があります. 

•基本的には，モジュール単位でテストすることになるので，エラーが発生したとき，あ 
やまり部分をみつけやすい. 

それまでうまく稼動していたものが，新たなモジュールを追加してテストした結果，うま 
く稼動しなくなったときは，新たに追加したモジュールに欠陥がある可能性が高く，その 
モジュールを集中的に調べることにより，デバッグ作業を効率化できます(図8 .6) 

春下位モジュールのテストは，結果として，テスト済の上位モジュールの再テストを行っ 
ていることにもなる（図 8.7). 

一般に，上位モジュールほど，プログラムでは重要な役割をはたしますので，重要な部分 
を何度も再 テス トできるのはプログラムの品質向上に大変役立ちます. 

•基本的には，プログラムの実行順序にそってテストできる. 

このことは，本番稼動の実環境のもとですベてのモジュールのテストができることを意味 
します.特に，モジュール間のインターフヱースのテストが実環境のもとでできることの 
意義を大きく評価する必要があります(図 8.8). 

•上位モジュールのテストでは，下位モジュールをスタブとして扱うため1〇〇 %完全にテ 
ストすることができない. 
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図 8. 5最上位モジュールを最初にテストできる 



図 8. 6新モジュール C のテスト時のエラーは新モジュールに原因のある可能性が高い 




図 8. 7モジュール B のテストはモジュール A の再テストにもなる 



図 8. 8実行順でテストすれば，実環境のもとでインターフヱースのテストができる 
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100%完全なテストが可能になるのはすベての下位モジュールがスタブでなく実モジ ュー 
ルに拡張されたときです.したがって，それぞれの時点で，各モジュールがどこまでテス 
卜されたのかを注意深く管理する必要があります. 

8.2 具体例でトップ•ダウン•テストの方法を考えてみよう 


前節でトップ • ダウン.テストの原理については理解できたと思いますので，ここで例 
題にそれを適用してみましょう. 

まず，いままでに何度もみてきた大気汚染度を測定する問題について適用してみます. 
この 問題の最上位 モジュールは 「大気汚染度を測定する」です.最初に このモジュールを 
テストします.その場合，3つの直接従属 モジュールは スタブとして扱います（図 8.9). 
コーディングは次のような形になっているでしょう. 

大気汚染度を測定する（テスト • モジュール） 

# define datasize 60 

# define endHour 24 
main () 

{ 

long ppm [ datasize ]; 
int hour ； 
double mean ; 

for(hour = l;hour < = endHour ;hour 4-+) 

{ 

getdata ( ppm ); 

cmean ( datasize , ppm )； 

putmean ( hour , mean ); 

} 
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1時間の測定値を得る（スタブ） 
getdata ( ppm ) 
long ppm [] 

{ 

printf (” getdata CALLED \ n ”); 


1 時間の平均値を得る（スタブ） 
cmean ( datasize , ppm ) 
int datasize ; 
long ppm []; 

{ 

printf (” cmean CALLED \ n ”); 


平均値を印刷する（スタブ） 
putmean ( hour . mean ) 
int hour ； 
double mean ； 

{ 

printf( M putmean CALLED \ n "); 


図 8.9 最上位モジュールのテスト 
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この段階では，テストの目的は最上位 モジュール 「大気汚染度を測定する」の制御論理 
をテストすることにあります.すなわち，1時間 ごとに 3 つの 従属 モジュール getdata; 
cmean, putmean が呼出されるかをテストすることにあります. getdata，cmean, 
putmean の3つの関数そのものが正しく実行されるかどうかはテストの対象外です•し 
たがって，これらはそれぞれスタブとして扱い，実際の論理でなく，呼出されたことを確 
認するだけのメッ セージを 書出すようになっています. 

特に， cmean は実際には平均値を返す機能を実行するのですが，この段階ではそれを 
行っていませんので， main モジ ュ ー ルの命令の一部が実際とはちがったものになってい 
ます. main が実際に実行するときは 



が実行されるのですが，この段階では 
cmean ( datasize , ppm ) , 

になっています. 

このように，テストのためにやむをえず実際のコーディングと異なった形にすることも 
ありますが，当然スタブが実コードに拡張されたとき， main の方も実際のコードに変え 
ます.しかし，このような変更はできるだけ少なくするように工夫することが必要です. 

main モジュールのテストが終了すれば，次は「1時間の測定値を得る」モジュールを 
テストしますこのモジュールのスタブを実コードにおきかえます（図 8. 1〇). 


図8.10 「1時間分の測定値を得る」モジュールのテスト 


大気汚染度 
を測定する 



測定値を得る [ Ji を計算する」 [_ 出力する_」 








8.2 具体例でトップ•ダウン•テストの方法を考えてみよう191 


実コードはつぎのようになります. 

1時間の測定値を得る（実コード） 

# define endMin 60 
getdata ( ppm ) 
long ppm []； 

{ 

int minute ； 

for(minute = 0 ;minute く endMin;minute ++) 

. { 

scanf (”％ d”，ppm [ minute ])； 
printf (” ％ ld / n”，ppm [ minute ])； 


これにより， 1 分ごとの測定値が 60 個，すなわち1時間分の測定値が ppm [0] から 
ppm [59] に入力される過程がテストされます.もちろん，この場合，テスト•データと 
して測定値を用意しでおく必要があります. 

このテスト用モジュールには ， ppm [0] から ppm [59] に測定値が入力されたことを 
目でたしかめるために 

printf ぐ‘％ 1 da / n”，ppm [ minute ]) ； 

が換入してあります.テストが完了すれば，この命令を取除くことになります. 
getdata モジュールの テストが終了すれば， つぎは mean モジュールの テストです（図 

図 8. 11「1時間の平均値を計算する」モジュールのテスト 
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8.11). cmean モジュールはスタブから次のような実コードにおきかえられます. 

平均値を計算する（実コード） 
cmean ( datasize , ppm ) 
int datasize ; 
long ppm []； 

{ 

double sum ; 
int i ; 
sum = 0.0; 

for ( i =0; i く datasize ; i + +) 

{ 

if (ppm [ i ] ==0) 

{ 

sum =0.0; 
break ； 

} 

else 

sum + 二 ppm [ i ]; 

} 

retnrn ( sum / datasize ); 

} 

このテストに際し， main モジュール内の 

cmeamdatasize ， ppm )； 


の部分は 
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mean=cmean ( datasize , ppm ) ； 

に戻す必要があります.また，平均値が正しく計算されたことを確かめるために上の命令 
文に続いて 

printf (“％6.0 fln ”， mean ) ； 

を換入し，計算結果を目に見える形で表示してもよいですが，この例の場合は putmean 
がその役割をはたすように定められているので， mean のテスト時に putmean のテスト 
も同時に行ってしまうのがよいでしょう. 

なお， このモジュールの テストにさいし，テスト•データ（測定値）として，正しい値を 
もった測定値と装置が故障した時の測定値(0, 0) の両方を用意し，それぞれに対して適切 
な処理が行われることを確かめる必要があります. 
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9. 新製品経済性評価プログラムの 
設計を行おラ 


これまでの説明でプログラム設計に対する基礎的な考え方は十分理解していただけたと 
思います. 

そこで，この章ではその応用として，いままでとは違った少し本格的な問題に対するプ 
ログラム設計に取組んでみましよう. 

9.1 問題仕様 

—<新製品経済性評価プログラム〉- 

新製品を開発するにあたり，発売後の売行きとコスト（費用）を予測することにより， 
その製品が企業の利益に貢献するか否かを評価したい.そのためのプログラムを作成 
する. 

発売後の売行きとコストは，企画部で設定した条件をもとに予測する.設定条件の 

図 9.1 新製品経済性評価報告書 
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詳細は後述する. 

評価を行う期間は最長10年間とするが，実際の評価期間(年数）はプログラムの実 
行のつど，入カパラメータとして指定する. 

指定された評価期間に対し，月毎に損益計算を行う.結果は図 9.1 のような形式で 
出力する. 

毎月の損益計算は次のように行う 

損益=売上額一必要費用 

売上額=販売個数 x 販売単価 

必要費用=給与+フロア経費十諸経費 
+コミッション+宣伝費 
+製造金額+保管運送費 
+各月に配分された初期費 

損益計算のために必要な各項目は，企画部が用意した予測のための基礎データにも 
とづいて算出される. 

企画部の用意した基礎データは次のとおり. 

P1 発売時この製品を販売するために P1 人のセールスマンを持つ.セールス 

マンはこの製品を専用に販売するものとする. 

P2 セールスマンは，毎月 P2 の比率で退職する. 

P3 入社して最初の月は，セールスマンは P3 個を販売出来る. 

P4 2 月目以降セールスマンは彼の前月の売上に比べて P4 の比率で売上個数 
を伸ばしていく. 

P5 セールスマンは 1 月に最大 P5 個しか販売出来ない. 

P6 発売して最初の月は，会社全体で P6 個の売上げがある. 

P7 毎月会社全体の売上個数は前月に比べて P7 の比率だけ増加していぐ 

P8 1 月当り会社全体で最大 P8 個までは売上をのばせる. 

P9 発売時，セールスマンの初任給は P9 百円とする. 
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P 10 4力月毎にセールスマンの基本給は P10 の比率で上昇する. 

P11 4力月毎にセールスマンの初任給は P11 の比率で上る. 

P12 セールスマンには毎月彼の販売成績の P12 に等しいだけの金額がコミッ 
ションとして支払われる. 

P13 セールスマン10人毎に P13 人の管理者を必要とする.管理者はこの製品 
のためにだけ存在するものとする. 

P14 この製品を販売するために最低 P14 人の管理者は必要である. 

P15 管理者1人について P15 人のスタッフを必要とする. 

P16 発売時管理者の初任給は P16 百円とする. 

P17 4力月毎に管理者の基本給は P17 の比率で上昇する. 

P18 4力月毎に管理者の初任給は P18 の比率で上昇する. 

P19 毎月 P19 の割合の管理者が退職する. 

P20 発売時スタッフの初任給は毎月 P20 百円とする. 

P21 4力月毎にスタッフの基本給は P21 の割合で上昇する. 

P22 4力月毎にスタッフの初任給は P22 の割合で上昇する. 

P23 毎月スタッフの P23 の割合の人が退職する. 

P24 当初，製品の製造価格は1個当り P24 百円とする. 

P25 当初，製品の販売価格は1個当り P25 百円とする. 

P26 製造価格は4力月毎に P26 の割合だけ高くなる. 

P27 事務所のフロア•スペースを拡張する度に，販売価格は P27 の割合で高く 
なる. 

P28 当初のフロア.スペースは管理者1人当り P 28 m 2 の25 %増しの広さでス 
タートする. 

このフロア.スペースが管理者1人当り P28m 2 より狭くなると，その時 
の10 %に当る広さを拡張するものとする. 

P29 発売時フロア.スペース1 m 2 当り毎月 P29 百円の経費が必要である. 

P30 フロア.スペースの経費は4力月毎に P30 の割合で増加する. 

P31 什器備品，清掃費等の諸経費として，その月のフロア•スペース経費の 
P31 に相当する額が必要である. 

P32 最初の4力月間，毎月の宣伝広告費として，その月の全セールスマンの給 
与の P32 の割合を計上する. 
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P33 5 力月目以降毎月の宣伝広告費として，過去 4 力月間に支払ったコミッシ 
ョン合計の P33 に相当する金額を計上する. 

P34 製品の保管費，運送費としてその月の製造金額の P34 に当るだけの経費 
が計上される. 

P35 発売にあたっての初期費は，発売当時のセールスマン 1 人当り P35 百円 
必要とする.この費用は，これから評価しようとする年数または 4 年間の 
どちらか短い方を，その期間毎月均等に配分されるものとする. 

P36 評価年数は P36 で指定される.最大 10 年間とする. 

(注） 4 力月毎とは発売月から数えての意味である. 


9.2 問題の分析 

9.1 で述べられた仕様をもとに，この問題の分析をしてみることにします.特に，企画 
部が用意した評価のための基礎データを慎重に分析する必要があります. 

分析のねらいは， P1 〜 P36 の基礎データが毎月の損益計算にどのように関係している 
かを知ることにあります. 

•販売個数の算定 

まず，売上額を計算するために，販売個数を知る必要があります.販売個数に関係する 
基礎 データは P6 ， P7 ， P8 です. 

発売して最初の月の販売個数は P 6 個です.その後，月毎に P 7 の比率で前月より販売 
個数が増えていきます.ただし，最大販売個数は P 8 個までです. 

発売月の販売個数二 P 6 

発売月から n 力月後の販売個数二 P6(l + P7)” 

ただし P6(1 + P7)^P8 


•販売単価の算定 

販売単価に関係する基礎データは P 25， P 27 です.発売月の販売単価は P 25 です•し 
かし，事務所のフロア.スペースが拡張されるたびに， P 27 の割合で高くなります. 
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発売月の販売単価二 P 25 

フロア • スペースが拡張されたときの販売単価=旧販売単価 （1 + P 27) 

このことから，フロア•スペースがきまらないと，販売単価がきまらないことに注意して 
下さい.フロア.スペースは管理者の数に依存しています （ P 28). 

•売上額の算出 

売上額は販売個数に販売単価を乗じて算出できます 
売上額=販売個数 X 販売単価 

次に，必要費用の算出方法について分析します.必要費用は下記の8つの費用の合計と 
して算出できます. 

人件費(給与） 

フロア経費 
諸経費 

コミッション 

宣伝費 
製造金額 
保管運送費 

各月に配分された初期費 


•人件費(給与)の計算 

この製品の販売には， セールスマン， 管理者，スタッフの3つの職種が関係して います . 
したがって，人件費はこの3つの職種の人件費の合計として算出できます. 

人件費=セールスマンの人件費+管理者の人件費+スタッフの人件費 


この式を計算するにはセールスマン，管理者，スタッフの人数と給与額を知る必要があ 
ります. 
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•セールスマンの数の算出 

セールスマンの数は，基本的には，販売目標(販売個数）によって決まります. 

販売目標を達成するのに必要な数のセールスマンがいないときは，不足分を新規採用す 
る必要があります. 

n 力月目の会社全体の販売目標(個数）は次のような式で計算できます. 

n 力月目の販売目標=発売月の売上個数 (1 + P 7” 

これに対し， n 力月目の会社全体のこの製品に対する販売能力は次のように算出できま 

す. 

n 力月目の販売能力= 2 ( J 力月目入社のセールスマン数 XJ 力月目入社セールス 

ノ =i 

マンの販売能力） 

入社後のセールスマンは毎月一定の比率 ( P 2) で退職していますので，セールスマン数 
を算出するときはこのことを考慮しておく必要があります. 

また，セールスマンの販売能力も毎月 P 4 の比率で向上することも考慮する必要があり 
ます.すなわち，セールスマンの販売能力は入社月ごとに異なるのです. 

このことは，入社月ごとにセールスマン数と販売能力を計算しなければならないことを 


図 9. 2セールスマン.テーブル 


図 9. 3販売能カテーブル 
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木各月毎に退職者数を算出し， 
人数を更新する 


氺各月毎に販売能力向上率 ( P 4) 
で能力値を更新する 
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意味しています. 

この観点から，上式をもう一度よく確認しておいて下さい.この式を計算可能にするた 
めに，図 9. 2,図 9. 3に示すようなテーブルが必要になるでしょう. 

このテーブルを用いれば， n 力月目に在籍しているセールスマンの数は 
n 力月目に在籍しているセールスマン数= 2 S ( i ) 

であり，その月に採用が必要な数は 

新規採用必要数 =( 販売目標個数一販売能力個数)/入社時セールスマン販売能力 （ P 3) 

になります.そして，その月のセールスマン総数は 

セールスマン総数二在籍セールスマン数十新規採用数 

です. 

❿管理者数の算出 

必要な管理者の数は，セールスマンの総数によって決まります.セールスマン10人ご 
とに必要な管理者数が P 13 で設定されます.また，管理者の最低必要人数が P 14 で設定 
されています. 

したがって，必要な管理者数は次の式で算出できます. 

管理者総数 =( セールスマン総数/ 10) P 13 
もし，この式で計算した管理者総数が P 14 より少なかったときは， 

管理者総数 = P 14 

になります. 

管理者も，セールスマンと同様，毎月一定の比率 ( P 19) で退職します.また，初任給や 
基本給は入社月によって異なってきますので，人件費の計算のためにも，セールスマンと 
同様の入社月ごとの管理者数を貯えておくテーブルが必要になります（図 9.4). 
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図 9.4 管理者テーブル 



ホ各月ごとに退職者を算出し，人数を更新する 


このテーブルを用いれば， n 力月目に在籍している管理者数は 
n 力月に在籍している管理者数=2 M ( i ) 


で求められます. 

したがって，もし保有数く必要総数ならば，その差の人数をその月に新規採用すること 
が必要になります. 

新規採用が必要な管理者数二必要管理者総数一在籍管理者数 
•スタッフ数の算出 

必要なスタッフの数は管理者の数によってきまります （ P 15). すなわち，管理者1人に 
対し P 15 人のスタッフが必要です. 

必要スタッフ総数二管理者総数 P 15 

その月に在籍しているスタッフ数が上式で計算した必要スタッフ数に満たないときは， 
その不足分を採用する必要があります.在籍スタッフ数は，セールスマンや管理者と同様， 
つぎのようなテーブル(図 9.5) を作成し，そこから算出します.テーブルは人件費の算出 
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図 9. 5 スタッフ•テーブル 



木各月ごとに退職者を算出し， 
人数を更新する 


のために必要になります. 

n 力月目に在籍しているスタッフ数= S F ( i ) 

新規採用が必要なスタッフ数=必要スタッフ総数一在籍スタッフ数 
ただし，在籍スタッフ数く必要スタッフ数のとき 


•退職者数の算出 

セールスマン， 管理者，スタッフとも毎月ある一定の比率 ( P 2， P 19, P 23) で退職して 
いきます. 

各職種ごとにその月に退職する人数はつぎの式で算出できます. 

退職者総数=在籍者総数 x 退職率 ( P 2, P 19, P 23) 

たとえば， n 力月目のセールスマンの場合は 
セールスマン退職者総数 =(2 S ( i )) xP 2 
となります，また，退職者は入社の古い者から順に退職していくものとします. 
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いま，退職者総数が15名と算出されたとすると，更新前のセールスマン•テーブルの状 
況が図 9. 6のようであれば，更新後は図 9.7 のようになります.すなわち，1力月目入社 
の10名がまず全員退職し，残りの5名は2力月目入社の者が退職することになります. 

先の人数計算のために用いるのは，更新後のテーブルを用いることになります. 


❿人件費(給与)算出の詳細 

先に人件費は， セールスマン， 管理者，スタッフの人件費の合計として算出する必要が 
あることを述べました.そして，職種ごとの人件費を算出するためには，それぞれの人数 


図 9.6 


更新前のセールスマン•テーブル 図 9. 7更新後のセールスマン•テーブル 
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(更新後) 


図 9. 8 

セールスマン 基本給 テーブル 


図 9. 9 図 9.10 

管理者基本給 テーブル スタッフ 基本給 テーブル 
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を知っおく必要があり，その人数の算出方法につし、ていままで説明してきました. 

特に初任給や基本給は入社月ごとに異なりますので，入社月ごとの人数を明確にする必 
要があり，そのための テーブルの 説明も行いました. 

正確な人件費を求めるためには職種ごと，入社月ごとの基本給を算出しておく必要があ 
ります. 

初任給 

発売月：初任給二 P 9( セールスマン)， P 16( 管理者)， P 20( スタッフ） 

4力月ごとに：初任給=旧初任給 （ 1+上昇率） 

上昇率：セールスマン （ P 11) 

管理者 ( P 18) 

スタッフ ( P 22) 


基本給 

入社月：基本給二初任給 
4力月ごとに：基本給=旧基本給 （ 1+上昇率） 

上昇率：セールスマン （ P 11) 

管理者 ( P 17) 

スタッフ （ P 21) 

上記の算式によって，職種ごと，入社月ごとの基本給を算出し，次のような テーブルに 
貯えておくことが必要です(図 9. 8，図 9. 9，図9.10). 

結果として，人件費はつぎのようにして求めることができます. 

n 力月目の人件費=セールスマン人件費+管理者人件費+スタ ッ フ人件費 

= ••】 S ( i ) xSS ( i ) + 2 M ( i ) xMS ( i ) + i F ( i ) XFS ( i ) 
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•フロア.スペースと維持費の算出 

必要なフロア•スペースは，管理者数によって決まります.フロア経費および諸経費(什 
器備品，清掃費等）はフロア • スペースの大きさに比例して算出できます. 

必要なフロア • スペース 

発売月：フロア • スペースニ管理者総数 XP 28 X 1.25 

その他の月： フロア.スペース くその月の管理者総数 XP 28 のとき 
フロア.スペース=前月フロア.スペース x 1.1 

フロア.スペース 2その月の管理者総数 XP 28 のとき 
フロア.スペース=前月フロア.スペース 


フロア経費+諸経費 
発売月：フロア経費/ m 2 二 P 29 

4力月ごとに：フロア経費/ m 2 =( 旧フロア経費/ m 2 ) x(l + P 30) 

各月の フロア 経費二その月の フロア. スペース X ( フロア 経費/ m 2 ) 

各月の諸経費=その月のフロア経費 XP 31 

各月のフロア経費+諸経費二その月のフロア.スペース X ( フロア経費/ m 2 ) 

X (1 + P 31) 

•コミッションおよび宣伝費の算出 

コミッションは，各月ごとに売上額の一定比率 ( P 12) で支払われます. 

その月のコミッション=その月の売上額 XP 12 
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每月の宣伝広告費は，最初の4力月間に関しては全セールスマンの給与の一定比率 
( P 32) が計上されます. 

5力月目以降は，過去4力月間に支払ったコミッション合計の一定比率 ( P 33) が計上さ 
れます. 

宣伝広告費 

最初の4力月間：宣伝広告費二全セールスマン給与 XP 32 
5力月目以降：宣伝広告費=過去4力月間のコミッション合計 XP 33 

•製造金額および保管運営費の算出 

製品の製造金額は，当初，1個あたり P 25 です. 4力月ごとに一定比率 ( P 26) で高くな 
ります. 

製造金額 

発売月：1個あたりの製造金額 = P 25 
4力月ごとに：1個あたりの製造金額=旧製造金額 （1+ P 26) 

各月の製造金額二その月の販売個数 x 1個あたりの製造金額 
各月の商品の保管.運送費は，その月の製造金額の一定比率 ( P 34) で計上されます. 

保管 • 運送費 

各月の保管 • 運送費二その月の製造金額 XP 34 
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癱初期費の配分の算定 

発売にあたっての初期費は，発売当時のセールスマンの数に依存します.セールスマン 
1人あたり P 35 が必要になります. 


初期費=発売時のセールスマンの数 ( PI ) XP 35 


初期費の各月への配分は次のように行われます. 


評価年数 ( P 36 K 4 年のとき 
配分された初期費二初期費/ ( P 36 X 12) 
評価年数2 4年のとき 


配分された初期費=初期費/48 


9.3 構造化設計 

さて，いままで説明した問題仕様とそれにもとずく分析結果をもとに，いよいよ構造化 
設計にとりかかることにします. 

►問題構造の大要の把握 

第6章で述べた構造化設計の手順にそって考えれば，まず第1に，問題構造の大要を把 
握することですが，この問題はその意味では大変明確です. 

図 9. 11にこの問題の最上位構造を示します.この図から明らかなように，この問題は 
企画部が設定したデータをもとに，損益計算を行い，その結果を印刷出力することです. 
したがって，問題の最初の分割には，源泉/変換/吸収分割技法を用いることができます. 
図9 . 11の結果を用いて，問題の最上位構造を図9 • 12のように定めることができます. 
この問題はここまではごく簡単なのですが，このあとが少し難しくなります • 変換部分， 
すなわち，毎月の損益計算を行う機能をもっと詳細に分割していく必要があります. 
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図 9. 11問題の大要 


「新製品経済性評価を行う」 



最大抽象 最大抽象 

入力点 出力点 


► 「損益計算」機能の分割 

「損益計算」機能を部分機能に分割していくためには，そのなかでのデータの流れを正 
確に把握する必要があります.そのためには， 9.2 で分析結果をよく吟味しなければりま 
せん. 

損益計算の基本は，収入と支出を正確に計算し，その差を求めることです. 

損益=収入一支出 

毎月の収入を計算するためには，その月の販売個数と販売単価がわからなければなりま 
せん.先に分析したように，販売個数は設定データ （P 6, P 7, P 8) から簡単に求まりま 
すが，販売単価をきめるには フロア•スペースが 影響してきます.したがって， フロア* 
スペースの 算定をまたなければなりません.そして， フロア•スペースの 算定のためには， 
管理者数が必要になります.管理者数をきめるためには， セールスマン 数が必要です •セ 
ールスマン 数をきめるのは販売個数です.この関係をわかりやすく図示すると 図 9. 13 の 
ようになります. 


図 9. 12 「経済性評価」プログラムの最上位構造図とインターフヱース 
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図 9. 13 「収入」計算のためのデータの流れと機能 



次に支出の計算について考えてみましょう.支出項目は，先にみたように，給与，フロ 
ア経費，諸経費，コミッション，宣伝費，製造金額，保管運送費，各月に配分された初期 
費の8つです. 

これら項目の計算方法については，すでに明らかにしましたが，計算のために必要なデ 
一夕の流れを明確にすることによって，必要な機能も定義できます(機能は入カデータか 
ら出カデータへの変換過程であることを思い出して下さい）. 

給与計算のためには，セールスマン数，管理者数，スタッフ数が必要になります(図 


図 9. 14 「給与計算」のためのデータの流れと機能 



給与計算 
を行う 
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図 9. 15 「フロア 経費」と「諸経費 j 計算のためのデータの流れと機能 



9.14). 

フロア経費，諸経費の計算のためには，管理者数が必要になります(図9.15). 

コミッシヨン計算には売上金額，宣伝広告費計算には全セールスマン給与とコミッシヨ 
ン額が必要です(図9 .16). 

製造金額計算のためには販売個数，保管運送費計算のためには製造金額が必要です(図 
9.17). 

特にふれませんでしたが，もちろん，各項目の計算にはこの他にいくつかの設定データ 
が必要になります（モジュール•インターフヱースを定義するときはこの設定データも必要 
になります). 

以上のデータの流れを全体図として示すと図 9. 18のようになります. 

図 9. 18は損益計算のための主要なデータの流れを示すと同時に，損益計算を行うため 
に必要な機能も示ています. 


図 9. 16 「コミッション」 と「宣伝広告費」計算のためのデータの流れと機能 



セールスマン数ゴ給与計算 
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図 9. 17 「製造金額」と「保管運送費」計算のための データの 流れと機能 



►全体構造の作成 

これをもとに，新製品の経済性評価問題の機能展開図を作成すると図 9. 19のようにな 
ります- 

この図で， 販売個数計算，人数計算（セールスマン，管理者，スタッフ），フロア•スぺ 
ース計算の3つは販売活動をとらえるものとして求めている点に注意して下さい. 


図 9. 18 「損益計算を行う」の全体 データ • フロー • ダイヤグラム 
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図 9. 19 「経済性評価」プログラム問題の機能展開図 


販売個数 
を計算する 


経済性評価 
を行う 


設定条件を 


毎月の損益 


結果を印刷 

得る 


計算を行う 


する 


販売活動を 
とらえる 


損益計算 
を行う 



人数計算 
を行う 


フロア•スペー 
スを計算する 


収入 
を求める 


支出 
を求める 



毎月の損益 
を求める 


ここでまとめた機能は，収入と支出を求めるために必要な販売活動をベースにした基礎 
データであり，直接の収入，支出計算と区分けすることにより，問題全体の理解度の向上 
に役立っています. 

もし，これらの機能を収入，支出計算の一部に混在させれば，問題の焦点をぼかしてし 
まうきらいがあります. 

なお，図 9. 19で機能を示す長方形枠の右下をぬりつぶしてあるものは，概念的な機能 
であり，問題の理解を容易にするために換入してあります.これらの機能によって，問題 
がより階層的に整理されていることをくみとっていただけたらと思います. 

これらの機能は，実際にモジュール化するときは特に必要でなくなることが多く，省略 
されることがよくあります.この問題でも，コーディング対象になるモジュールを考える 
段階では，これらの概念的な機能は削除してあります. 

►モジュール構造の作成 

図 9. 20はそのモジュール構造を示しています.また，図 9. 21はモジュール間インター 
フェースを示しています.図 9. 22はこれら記号で示されたインターフヱースの意味をま 
とめたものです. 

「退職人数を計算する」と「給与計算を行う」モジュールが共通モジュールとして設計 
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図9 .20 

「経済性評価」プログラムの 
モジュール構造図 


PREDICT 
経済性評価を行う 


GET 

DATA 

設定条件を得る 

r 

COMPUTE 
RESULTS 
毎月の損益 
-を計算する - 

ハ 

PRINT 

REPORT 

結果を印刷する 


14 [ 


16 I 
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SALESMEN，S 


MANAGER'S 

STAFF 

PAYROLL ， 

FLOOR 

SOLD 


PROFILE 


PROFILE 

PROFILE 
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売上個数を 


セールスマン数 


管理者数を 

スタッフ数 


MAINT 

フロア•スペースとの 

計算する 


を計算する 


計算する 

を計算する 
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維持費を計算する 
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REVENUE 


COMMISSION 
& ADVERT 

売上金額を 


コミッションと宣伝 

計算する 


広告費を計算する 



図 9. 21 「経済性評価」プログラムのモジュール•インターフヱース 



入 

出 

1 

無し 

PI 〜 P36 

2 

MONTH, P6, P7, P8 

UNITS-SOLD 

3 

MONTH, PI,P£, P3, P4, P5, UNITS — 

SOLD 

* SALESMEN, * TOT-SALESMEN 

4 

MONTH, P13, P14, P19, 

TOT-SALESMEN 

氺 MANAGERS, * TOT-MANAGERS 

5 

MONTH, P15, P23, TOT-MANAGERS 

* STAFF, * TOT —STAFF 

6A 〜 6C 

MONTH, START-SAL, CURRENT- 
RAISE, START-RAISE, PEOPLE 

*PEOPLES-SAL, ホ PEOPLES — 
BEGIN-SAL, TOT-PEOPLES-SAL 

7 

MONTH, TOT-MANAGERS, P28, 

P29, P30, P31 

FLOOR- SPACE - AND- MAINT- 
COST, * FLOOR-AREA 

8 

MONTH, P25, PE7, FLOOR-AREA, 

UNITS-SOLD 

REVENUE 

9 

MONTH, P12, P3S, P33, REVENUE, 

TOT-SALESMENS-SALS 

COM-ADVERT-COST 

10 

MONTH, PE4, P26, P34, UNIT-SOLD 

TOT- UNIT- COST- AND - STORAGE 

11 

MONTH, PI, P35, P36 

SET-UP-COST 

12 

MONTH, P25, P27, FLOOR-AREA, 

UNITS-SOLD 

PROFIT-SAVE 

13 

P36, PROFIT-SAVE 

無し 

14-16 

PEOPLE, TOT-PEOPLE, RESIG- 

PACTOR 

PEOPLE, TOT-PEOPLE 


(注）： （1)* 印は入出力共用 

(2) 6 A -6 C , 14〜16はセールスマン，管理者，スタッフの3職種で共通 
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図 9. 22 「経済性評価」ブログラムの主要変数説明図 


変 数 

説 明 

MONTH 

発売以来の各月. 

UNIT-SOLD 

各月毎の販売個数. 

SALESMEN (120) 

発売以来，各月毎に入社し，在籍しているセールスマンの人数. 

TOT-SALESMEN 

全セールスマンの人教. 

MANAGERS (120) 

発売以来，各 fl 毎に入社し，在籍している管理者の人数. 

TOT-MANAGERS 

全管理者の人数. 

STAFF (120) 

発売以来，各月毎に入社し，在籍しているスタッフの人数. 

TOT-STAFF 

全スタッフの人数. 

START-SAL 

発売時の初任給. =P9, P16 または P20 

CURRENT-RAISE 

基本給の上昇率. =P10, P17 または P21 

START-RAISE 

初任給の上昇率. =P11,P18 または PZZ 

PEOPLE (120) 

毎件計算の対象となる人. =SALESMAN, MANAGER, STAFF 

PEOPLES - SAL (1E0) 

各月毎に入社した人の 基本給 . 計算する時点で異なる. 

= SALESMENS-SAL (120), MANAGERS-SAL (ISO) または 
STAFF-SAL (ISO) 

PEOPLES-BEGIN-SAL 

各月に入社した人の初任給.入社時点により異なる. 

= SALESMENS-BEGIN- SAL, MANAGERS- BEGIN- 
SAL または STAFF - BEGIN - SAL 

TOT-PEOPLES-SALS 

計算対象の職種全員の給与合計. 

= TOT-SALESMENS - SALS, TOT-MANAGERS-SALS 
または TOT-STAFF-SALS 

PLOOR-SPACE-AND- 

MAINT-COST 

事業所のフロア.スペースを確保し維持する費用 

FLOOR-AREA 

事業所のフロア.スペース面稍 

REVENUE 

毎月の収入(売上金額） 

COM-ADVERT-COST 

毎月のコミッションと宣伝広告費合計. 

TOT-UNIT-COST-AND- 

STORAGE 

売上原価（製造金額と保管费，運送费とを合計したもの） 

SET-UP-COST 

各月に配分される初期費. 

PROFIT-SAVE (120) 

各月毎の損益 

RESIG-FACTOR 

職種別退職比率 =P2, P19 または P23 


(120)は配列として120個記憶域を確保する意味である. 


されている点に注意して下さい. セールスマン， 管理者， スタッフの 3つの職種に対する 
それぞれの処理に対して呼び出されることになります.この部分のイ ンターフヱース •デ 
一夕の設定が工夫されている点をよく学んでおいて下さい. 

また，フロア•スペースと諸経費の計算，コミッションと宣伝広告費の計算，製造金額 
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と保管運送費の計算が，それぞれ1つの モジュールに まとめられている点にも気をつけて 
下さい.これらの モジュールは， 強度的には連絡的強度になりますが，使用する データの 
観点から密接に関係があり，一緒にした方がコーディングが効率的に行えることが予想さ 
れるのでまとめてあります. 

その他のモジュールはすべて機能的強度になっており，また結合度としてはデータ結合 
になっていることをよく確かめて下さい. 

なお，インターフェース•データの説明に用いた変数名は，この後のコーディングでそ 
のまま用います. 

9.4 モジユールの論理設計 

構造化設計が終了すれば，次の作業は各モジュールの論理の設計です. 

図 9. 20に示した各モジュールの論理を疑似コードで設計した例を図 9. 23〜図 9. 35に示 
してあります. 


図9 . 23 「新製品の経済性評価を行う」の論理 


初期設定を行う 

入カデータ （ P 1 〜 P 36) を読取る 
入カデータを書き出す 

DO WHILE 評価期間 （ P 36 X 12) の各月に対して 
売上個数の計算する 
セールスマン数を計算する 
管理者数を計算する 
スタッフ数を計算する 
給与計算を行う 

事業所の面積と維持費を計算する 
売上金額を計算する 
コミッションと宣伝広告費を計算する 
製造金額と保管費，運送費を計算する 
初期費を各月に配分する 
毎月の損益を計算する 
損益を損益テーブルに移す 
ENDDO 

各月ごとの損益と合計を書き出す 

END PREDICT 
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図 9. 24 「販売個数を計算する」の論理 


IP 発売月 

売上個数 =P6 

ELSE 

売上個数=前月の売上個数 （ 1 +P7) 

BNDIF 

IP 売上個数 >P8 

売上個数 =P8 

ENDIP 

END UNITS-SOLD 


09.25 「セールスマン数を計算する」の論理 


IF 発売月 

初期設定を行う 

ELSE 

退職者を算出して，在籍人数を更新する 
販売能力を更新する 

在籍人数による販売能力（個数）を計算する 
IF 販売能力<売上目標 
必要数を採用する 

ENDIP 

ENDIP 

END SALESMENS-PROFILE 


図 9. 26 「管理者の数を計算する」の論理 


IF 発売月 

初期設定を行う 

ELSE 

退職者を算出して，在籍人数を更新する 
必要な管理者数を計算する 
IP 在籍人数< 必要管理者数 
必要数を採用する 

ENDIF 

BNDIF 

END MANAGER-PROFILE 
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図 9. 27 「スタッフ数を計算する」の論理 


ip 発売月 

初期設定を行う 

ELSE 

退職者を算出して，在籍人数を更新する 
必要なスタッフ数を計算する 
IF 在籍人数 < 必要スタッフ数 
必要数を採用する 

ENDIP 

ENDIP 

END STAFF-PROPILE 


図 9. 28 「退職者数を計算する」の論理 


退職者総数を算出する 

在籍者総数を更新する（新在籍者総数を求める） 
在籍者テーブルを更新する 
END RESIGN 


図 9. 29 「給与計算を行う」の論理 


IP 発売月 

初任給=発売時初任給 ( P 9， P 16, PZO ) 

ELSE 

IF 昇給時 （4 力月ごと） 

初任給=旧初任給 （ 1+上昇率） 
DOWHILE 入社月くその月 
基本給=旧基本給 （ 1+上昇率） 

ENDDO 

ENDIF 

ENDIP 

DOWHILE 入社月 S その月 

入社月ごとの給与=人数 X 基本給 

給与合計=前月までの給与合計+入社月ごとの給与 

ENDDO 

END PAYROLL 
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図 9. 30 「フロア • スペースと 維約費を計算する」 の 論理 


IP 発売月 

フロア • スペース=管理者総数 XP28X1.25 
フロア経費 = P 29 

ELSE 

IF フロア.スペースく管理者総数 XP28 

フロア*スペース=旧フロア.スペース X 1.1 
ENDIP 
IF 4 力月ごと 

フロア経費=旧フロア経費 X( 1 +P30) 

ENDIP 

ENDIF 

フロア . スペース経費と維持費の和 = フロア経費 + フロア • スペース （ 1 +P31) 
END FLOOR-SPACE-AND-MAINT 


図 9. 31「売上額を計算する」の論理 


IP 発売月 

販売単価 = P25 

ELSE 

IP 当月フロア•スペース>前月フロア•スペース 
販売単偭=販売単価 （ 1 4-P27) 

ENDIP 

ENDIF 

売上額=販売個数 X 販売単価 

END REVENUE 


図 9. 32 「コミッションと宣伝広告費を計算する」の論理 


コミツシヨン=売上額 XP12 
IP 最初の 4 力月 

宣伝広告費=全セ-ルスマン給与 X P32 

ELSE 

宣伝広告費=過去 4 力月のコミツシヨン合計 XP33 

ENDIP 

コミツシヨンと宣伝広告費の和=コミツシヨン十宣伝広告費 

END COMMISIONAND--ADVERT 
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図 9. 33 「製造金額と保管運送費を計算する」の論理 


if 発売月 

製造単価 = P 25 

ELSE 

IP 4力月ごと 

製造単価=旧製造単価 （ 1 + P 26) 

ENDIF 

ENDIF 

製造金額と保管運送費の和=製造単価 X 販売個数 （ 1 + P 34) 
END TOTAL - UNIT-COST AND STORAGE 


図 9.34 「初期費を各月に分配する j の論理 


IP 評価年数 ( P 36)<4 年 

配分した初期費=発売時セ-ルスマン数 ( P 1) XF 35/( P 36 X 12) 

ELSE 

配分した初期費=発売時セ-ルスマン数 XP 35/48 

ENDIF 

END SET-UP 


図 9. 35 「毎月の損益を計算する」の論理 


損益=売上額一 （ セ-ルスマン給与合計 
+管理者給与合計 
+スタッフ給与合計 
+フロア経費と維持費の和 
+コミッシヨンと宣伝広告費の和 
+製造金額と保管運送費の和 
+配分した初期費） 

END PROFIT 
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-ディスク • サービスの お知らせ- 

本書の最後の章で設計した「新製品の経済性評価」プログラムのソースと実行形式オブジヱクトをデ 
ィスク頒布いたします.ソースは C + + で書かれており，対応機種は PC -9801 シリーズ，テストに使用 
したコンパイラはボーランドの 「Turbo C + + ver 1.0」です.ご希望の方は下記の要領でお申し込みく 
ださい. 

なお，申し込みから発送までに2週間ほどかかることがございますのでご承知おきください. 
►プログラムの コンパイル， 実行のしかたなどは，頒布ディスクの README テキスト•フアイルに入 
っていますので， DOS の TYPE コマン ドなどでごらんください. 


ディスクの申し込み方法 

申し込み用紙に住所/氏名を記入して，代金3,000円(税，送料込み）とともに現金書留で 
お送りください. 

•メディア： 5.25 インチ 2 HD または 3.5 インチ 2 HD (いずれかを指定してください） 
〈宛先〉 

亍170東京都豊島区巣鴨 1-14-2 
CQ 出版 ㈱ C & E 出版部 
らくらく構造化設計係 
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■FINE SOFT C によるらくらく構造化設計 
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IFS-CRRI 

送り先ご住所：〒 
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